From nobody Sun Apr 3 07:59:28 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 AD88C12D176 for ; Sun, 3 Apr 2016 07:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Oa3RNeH6bZW for ; Sun, 3 Apr 2016 07:59: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 9F87912D127 for ; Sun, 3 Apr 2016 07:59:24 -0700 (PDT) Received: from dhcp-a19a.meeting.ietf.org (dhcp-a19a.meeting.ietf.org [31.133.161.154]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u33ExJcN087335 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 3 Apr 2016 09:59:20 -0500 (CDT) (envelope-from adam@nostrum.com) To: avtext@ietf.org, Peter Thatcher References: <56FD3492.8080600@ericsson.com> From: Adam Roach Message-ID: <57012FC5.7040705@nostrum.com> Date: Sun, 3 Apr 2016 11:59:17 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FD3492.8080600@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2016 14:59:26 -0000 On 3/31/16 11:30, Magnus Westerlund wrote: > Hi, > > Here are my comments on the draft-ietf-avtext-rid-01. I think it is > very good that we have an upcoming meeting where we can discuss the > below issues. > > 1. Abstract: > > This document defines and registers an RTCP SDES item, RID, for > identification of RTP streams associated with Encoded Streams and > Dependent Streams. > > Should this really use plural of RTP streams as well as Encoded > Streams. A particular RID value is the identifier for one Encoded or > Dependent Stream in its RTP packetized form plus. Thus I think this > abstract could be clearer. However, I think it may need to addressed > anyway based on comment 3 and 4. No; grammatically, what's in there makes sense. It might not be as obvious because we're talking about abstract concepts rather than concrete nouns, but this sentence is grammatically parallel to "This document defines and registers a metal label, called a "license plate", for identification of cars associated with drivers and passengers." (Yes, this isn't what license plates do, but I'm clarifying the grammatical structure, not the meaning). > > 2. Section 1: > > RTP sessions frequently consist of multiple streams, each of which is > identified at any given time by its SSRC; however, the SSRC > associated with a stream is not guaranteed to be stable over its > lifetime. Within a session, these streams can be tagged with a > number of identifiers, including CNAMEs and MSIDs > [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper > ordinality to refer to an individual stream; all such identifiers can > appear in more than one stream at a time. While approaches that use > unique Payload Types (PTs) per stream have been used in some > applications, > > I think the usage of Stream should at least on the first usage say > "RTP Stream" and with a reference to RFC7656 to make it clear what > entity you are discussing in this paragraph. How about "RTP sessions frequently consist of mutiple RTP streams (see section 3), each of which..."? > 3. Section 3: > > For Encoded Streams, the RID refers to the "Source RTP Stream" as > defined by [RFC7656] Section 2.1.10. For Dependent Streams, it > refers to the RTP Stream that, like the Source RTP Stream of an > Encoded Stream, is the RTP Stream that is not a Redundancy RTP > Stream. For conciseness, we define the term "RID RTP Stream" to > refer to this construct. > > I think this definition is not correct. From my perspective it might > be better to talk about the RTP stream produced by the media > packetizer from a encoded or set of dependent streams. I write a set > of dependent stream as on RTP stream can be produced by packetizing > multiple dependent streams in the same. This would occur if one is not > producing different RTP streams for all produced scalability layers. > > However, the main issue is that the definition does not correctly > identifies what the RID refers to. To my understanding the RID refers > to one RTP stream [A] packetized from either one encoded stream and > zero or more dependent streams, or one or more dependent streams and > the one or more redundancy streams protecting the RTP stream [A]. For WebRTC simulcast, at least, this isn't what we need. If we have one encoded stream and two dependent streams, this needs to result in three RIDs (regardless of the presence or number of redundancy streams). > This also has the consequence that RID RTP Stream is not a suitable > term as the RID identifies an possible aggregate of RTP streams, one > source and zero or more redundancy RTP streams. We need some concise term here, and I don't care what it is. I would personally be happy happy to change the term to "Spicy Mango Surprise" if it got us to finished. I just want a well-defined term that means exactly this construct. > 4. Section 3: > > For clarity, when RID is used, Redundancy RTP Streams that can be > used to repair Received RTP Streams will use the same RID value as > the Received RTP Stream they are intended to be combined with. If > applications want to identify individual redundancy streams, they can > add an RRID to them instead of or in addition to the RID. > > So the intention with RRID, is to identify Redundancy RTP streams. > Considering that RID doesn't actually only represent the source RTP > stream for the media, there is a mismatch. I'm confused. If I read the text you quoted above, it's pretty clear: "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It then builds a parallel construct for dependent streams, but these are always going to have a different RID than their corresponding encoded streams. > Also, the needs for RRID is also not clear, however, the basics of > identifying the RTP stream only has the advantage of high likelihood > of re-use in other mechanisms. This came out of discussions with Colin, which I interpreted as a request to add a means to uniquely identify redundancy streams. The *current* discussion seems to be leaning toward removing RRID, although I'm waiting to hear from others on the topic still. > Some may protest, hey but we are loosing the coupling method between > the source RTP stream and the Redundancy stream. Yes, I have a > proposal below for how to resolve that, but at the same time, it is > this coupling that creates the complicated definition of the RID SDES > item. And this is actually quite a separate problem. One which has > existed for some time, and may actually benefit from being taken on a > separate work item. Especially as we may want to retrofit the outcome > onto some existing mechanisms such as RTP Retransmission and Generic > XOR FEC to enable single RTP session usage efficiently for both. > > So below is a possible solution if one desire to have a way of > coupling the redundancy stream to the source RTP stream already in > signalling and identifying it with the same properties as we get with > RID for the Source RTP streams. > > The solution is simple, we simply have a=RID lines also for the > Redundancy RTP streams. Then we define a new constraint which I will > call "protect" which is a list of SIDs that points at one or more RTP > streams for which this Redundancy RTP Stream is constrained to protect > and provide redundancy for. We already had several rounds of discussion on this topic, and I made a proposal that is functionally equivalent to what you're proposing. The problem that was raised is that making this change forces the WebRTC API to expose multiple identifiers associated with a single WebRTC construct. Basically, you can make the protocol slightly more complicated and the API slightly simpler, or you can make the protocol slightly simpler and the API slightly more complicated. There are a couple of tie breakers here, both pointing to the API being simpler: (1) the API is already defined and effectively frozen (WebRTC is trying to get the document to stop changing so it can be published); and (2) the priority of constituencies (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) prioritizes authors over implementors in protocol trade-offs, and this calls for simplifying the API rather than the wire protocol. I recognize that this is a W3C principle rather than an IETF principle, but it remains sound advice in general. > 5. Section 4 and 6. > > What I am missing in this is a discussion of privacy and the potential > for tracking the streams across an RTP system. This is usually fine, > but may reveal things to a third party, thus their value should be > protected towards third parties. If you can point me to similar language in another document for SSRC, I'd be happy to copy it directly into this document. > The next part of this issue is the generation of these values should > avoid leaking any information about the user and implementation. This > leads to the question if the values should be using random values, > with tag lengths as needed by the application. In practice, since these are scoped to the sending endpoint, I would expect most implementations to use a very simple scheme, like a single-character representation that starts with "0", works through "9", and then steps up to "a" through "z", moving on to two-character identifiers if they use more than 36 streams. /a From nobody Mon Apr 4 03:28:14 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF9A12D1E9 for ; Mon, 4 Apr 2016 03:28:12 -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 O3g8lfqnSosk for ; Mon, 4 Apr 2016 03:28:10 -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 67A1D12D0CE for ; Mon, 4 Apr 2016 03:28:10 -0700 (PDT) Received: from [130.209.247.112] (port=58468 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 1an1jr-0008Lm-HJ; Mon, 04 Apr 2016 11:28:08 +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: <57012FC5.7040705@nostrum.com> Date: Mon, 4 Apr 2016 11:28:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C748B18-125E-4C0F-9FB9-70169AC9F888@csperkins.org> References: <56FD3492.8080600@ericsson.com> <57012FC5.7040705@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 10:28:13 -0000 > On 3 Apr 2016, at 15:59, Adam Roach wrote: >=20 > On 3/31/16 11:30, Magnus Westerlund wrote: >> Hi, >>=20 >> Here are my comments on the draft-ietf-avtext-rid-01. I think it is = very good that we have an upcoming meeting where we can discuss the = below issues. >>=20 >> 1. Abstract: >>=20 >> This document defines and registers an RTCP SDES item, RID, for >> identification of RTP streams associated with Encoded Streams and >> Dependent Streams. >>=20 >> Should this really use plural of RTP streams as well as Encoded = Streams. A particular RID value is the identifier for one Encoded or = Dependent Stream in its RTP packetized form plus. Thus I think this = abstract could be clearer. However, I think it may need to addressed = anyway based on comment 3 and 4. >=20 > No; grammatically, what's in there makes sense. It might not be as = obvious because we're talking about abstract concepts rather than = concrete nouns, but this sentence is grammatically parallel to "This = document defines and registers a metal label, called a "license plate", = for identification of cars associated with drivers and passengers." = (Yes, this isn't what license plates do, but I'm clarifying the = grammatical structure, not the meaning). >=20 >=20 >>=20 >> 2. Section 1: >>=20 >> RTP sessions frequently consist of multiple streams, each of which is >> identified at any given time by its SSRC; however, the SSRC >> associated with a stream is not guaranteed to be stable over its >> lifetime. Within a session, these streams can be tagged with a >> number of identifiers, including CNAMEs and MSIDs >> [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the = proper >> ordinality to refer to an individual stream; all such identifiers = can >> appear in more than one stream at a time. While approaches that = use >> unique Payload Types (PTs) per stream have been used in some >> applications, >>=20 >> I think the usage of Stream should at least on the first usage say = "RTP Stream" and with a reference to RFC7656 to make it clear what = entity you are discussing in this paragraph. >=20 > How about "RTP sessions frequently consist of mutiple RTP streams (see = section 3), each of which..."? >=20 >=20 >> 3. Section 3: >>=20 >> For Encoded Streams, the RID refers to the "Source RTP Stream" as >> defined by [RFC7656] Section 2.1.10. For Dependent Streams, it >> refers to the RTP Stream that, like the Source RTP Stream of an >> Encoded Stream, is the RTP Stream that is not a Redundancy RTP >> Stream. For conciseness, we define the term "RID RTP Stream" to >> refer to this construct. >>=20 >> I think this definition is not correct. =46rom my perspective it = might be better to talk about the RTP stream produced by the media = packetizer from a encoded or set of dependent streams. I write a set of = dependent stream as on RTP stream can be produced by packetizing = multiple dependent streams in the same. This would occur if one is not = producing different RTP streams for all produced scalability layers. >>=20 >> However, the main issue is that the definition does not correctly = identifies what the RID refers to. To my understanding the RID refers to = one RTP stream [A] packetized from either one encoded stream and zero or = more dependent streams, or one or more dependent streams and the one or = more redundancy streams protecting the RTP stream [A]. >=20 > For WebRTC simulcast, at least, this isn't what we need. If we have = one encoded stream and two dependent streams, this needs to result in = three RIDs (regardless of the presence or number of redundancy streams). >=20 >> This also has the consequence that RID RTP Stream is not a suitable = term as the RID identifies an possible aggregate of RTP streams, one = source and zero or more redundancy RTP streams. >=20 > We need some concise term here, and I don't care what it is. I would = personally be happy happy to change the term to "Spicy Mango Surprise" = if it got us to finished. I just want a well-defined term that means = exactly this construct. >=20 >> 4. Section 3: >>=20 >> For clarity, when RID is used, Redundancy RTP Streams that can be >> used to repair Received RTP Streams will use the same RID value as >> the Received RTP Stream they are intended to be combined with. If >> applications want to identify individual redundancy streams, they = can >> add an RRID to them instead of or in addition to the RID. >>=20 >> So the intention with RRID, is to identify Redundancy RTP streams. = Considering that RID doesn't actually only represent the source RTP = stream for the media, there is a mismatch. >=20 > I'm confused. If I read the text you quoted above, it's pretty clear: = "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It = then builds a parallel construct for dependent streams, but these are = always going to have a different RID than their corresponding encoded = streams. >=20 >=20 >> Also, the needs for RRID is also not clear, however, the basics of = identifying the RTP stream only has the advantage of high likelihood of = re-use in other mechanisms. >=20 > This came out of discussions with Colin, which I interpreted as a = request to add a means to uniquely identify redundancy streams. I suggested that, if RID is being used, every RTP stream in an RTP = session needs to have a unique RID.=20 A consequence of that would be that a redundant RTP stream would have a = different RID to the original RTP stream. However, that would be true of = any two RTP streams. > The *current* discussion seems to be leaning toward removing RRID, = although I=E2=80=99m waiting to hear from others on the topic still. I don=E2=80=99t see value in the RRID as specified.=20 I do see value in defining an =E2=80=9Cassociated RID=E2=80=9D header = extension. That would be a field that indicates a stream associated with = the current stream. For example, if the main RTP stream had RID=3DXXX = and the redundant RTP stream had RID=3DYYY, then the redundant RTP = stream could also contain an =E2=80=9Cassociated RID=E2=80=9D=3DXXX = header, to indicate which stream it is providing redundancy for. This is = similar to Magnus=E2=80=99 current proposal (and the arguments = for-and-against it were similar). Colin >> Some may protest, hey but we are loosing the coupling method between = the source RTP stream and the Redundancy stream. Yes, I have a proposal = below for how to resolve that, but at the same time, it is this coupling = that creates the complicated definition of the RID SDES item. And this = is actually quite a separate problem. One which has existed for some = time, and may actually benefit from being taken on a separate work item. = Especially as we may want to retrofit the outcome onto some existing = mechanisms such as RTP Retransmission and Generic XOR FEC to enable = single RTP session usage efficiently for both. >>=20 >> So below is a possible solution if one desire to have a way of = coupling the redundancy stream to the source RTP stream already in = signalling and identifying it with the same properties as we get with = RID for the Source RTP streams. >>=20 >> The solution is simple, we simply have a=3DRID lines also for the = Redundancy RTP streams. Then we define a new constraint which I will = call "protect" which is a list of SIDs that points at one or more RTP = streams for which this Redundancy RTP Stream is constrained to protect = and provide redundancy for. >=20 > We already had several rounds of discussion on this topic, and I made = a proposal that is functionally equivalent to what you're proposing. >=20 > The problem that was raised is that making this change forces the = WebRTC API to expose multiple identifiers associated with a single = WebRTC construct. Basically, you can make the protocol slightly more = complicated and the API slightly simpler, or you can make the protocol = slightly simpler and the API slightly more complicated. There are a = couple of tie breakers here, both pointing to the API being simpler: (1) = the API is already defined and effectively frozen (WebRTC is trying to = get the document to stop changing so it can be published); and (2) the = priority of constituencies = (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies)= prioritizes authors over implementors in protocol trade-offs, and this = calls for simplifying the API rather than the wire protocol. I recognize = that this is a W3C principle rather than an IETF principle, but it = remains sound advice in general. >=20 >=20 >> 5. Section 4 and 6. >>=20 >> What I am missing in this is a discussion of privacy and the = potential for tracking the streams across an RTP system. This is usually = fine, but may reveal things to a third party, thus their value should be = protected towards third parties. >=20 > If you can point me to similar language in another document for SSRC, = I'd be happy to copy it directly into this document. >=20 >> The next part of this issue is the generation of these values should = avoid leaking any information about the user and implementation. This = leads to the question if the values should be using random values, with = tag lengths as needed by the application. >=20 > In practice, since these are scoped to the sending endpoint, I would = expect most implementations to use a very simple scheme, like a = single-character representation that starts with "0", works through "9", = and then steps up to "a" through "z", moving on to two-character = identifiers if they use more than 36 streams. >=20 > /a >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ From nobody Mon Apr 4 07:26:20 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EAB12D70C for ; Mon, 4 Apr 2016 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJtUr7oN1sUc for ; Mon, 4 Apr 2016 07:26:16 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF9A12D70B for ; Mon, 4 Apr 2016 07:26:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79d86d000005b69-25-57027985cb18 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.60.23401.58972075; Mon, 4 Apr 2016 16:26:13 +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.248.2; Mon, 4 Apr 2016 16:26:10 +0200 To: Adam Roach , , Peter Thatcher References: <56FD3492.8080600@ericsson.com> <57012FC5.7040705@nostrum.com> From: Magnus Westerlund Message-ID: <5702797D.1020600@ericsson.com> Date: Mon, 4 Apr 2016 11:26:05 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <57012FC5.7040705@nostrum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2K7pW5rJVO4wcXjphZ7/i5it/h47war xbXlr1kdmD0WbCr1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy3s3uYy9YEV+x8Z1rA+Nu 7y5GDg4JAROJdys9uhg5gUwxiQv31rN1MXJxCAkcYZS4eGQrO4SzjFHi9M5zTCBVwgIWEn/n TGIHsUUEYiWW7nvKAmILCdRKvDh3kxnEZgOqufmjkQ3E5hXQltj5ZxFYPYuAisTLo22MILao QIzE8XfnGCFqBCVOznwCNocTqL590wZ2kOOYBewlHmwtAwkzC8hLNG+dzQyxSluioamDdQKj wCwk3bMQOmYh6VjAyLyKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzBED275bbWD8eBzx0OM AhyMSjy8C04xhguxJpYVV+YeYpTgYFYS4c0pZwoX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsT +S9MSCA9sSQ1OzW1ILUIJsvEwSnVwDhD7WxUyJkojlT7pC3yfwzihe4ls+YslP239GHAqq8C K/emneWUdk/m5DV+wv8uOLWL6f4CVZE4u0NP5jE6/6l1f16aKxfjPrP9J0vVzsYfF09w3Nj3 63l3Uc00RZ/v/xheWdsuOOhU8FyRZUX4XkdGLtklKyLUXc6KCuvmKPj9W9S95UyYphJLcUai oRZzUXEiAGxGh91NAgAA Archived-At: Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:26:19 -0000 Hi, Please see inline. I think there are some clarifications needed here. Den 2016-04-03 kl. 11:59, skrev Adam Roach: > On 3/31/16 11:30, Magnus Westerlund wrote: >> Hi, >> >> Here are my comments on the draft-ietf-avtext-rid-01. I think it is >> very good that we have an upcoming meeting where we can discuss the >> below issues. >> >> 1. Abstract: >> >> This document defines and registers an RTCP SDES item, RID, for >> identification of RTP streams associated with Encoded Streams and >> Dependent Streams. >> >> Should this really use plural of RTP streams as well as Encoded >> Streams. A particular RID value is the identifier for one Encoded or >> Dependent Stream in its RTP packetized form plus. Thus I think this >> abstract could be clearer. However, I think it may need to addressed >> anyway based on comment 3 and 4. > > No; grammatically, what's in there makes sense. It might not be as > obvious because we're talking about abstract concepts rather than > concrete nouns, but this sentence is grammatically parallel to "This > document defines and registers a metal label, called a "license plate", > for identification of cars associated with drivers and passengers." > (Yes, this isn't what license plates do, but I'm clarifying the > grammatical structure, not the meaning). > Ok > >> >> 2. Section 1: >> >> RTP sessions frequently consist of multiple streams, each of which is >> identified at any given time by its SSRC; however, the SSRC >> associated with a stream is not guaranteed to be stable over its >> lifetime. Within a session, these streams can be tagged with a >> number of identifiers, including CNAMEs and MSIDs >> [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper >> ordinality to refer to an individual stream; all such identifiers can >> appear in more than one stream at a time. While approaches that use >> unique Payload Types (PTs) per stream have been used in some >> applications, >> >> I think the usage of Stream should at least on the first usage say >> "RTP Stream" and with a reference to RFC7656 to make it clear what >> entity you are discussing in this paragraph. > > How about "RTP sessions frequently consist of mutiple RTP streams (see > section 3), each of which..."? > Yes, that is fine. > >> 3. Section 3: >> >> For Encoded Streams, the RID refers to the "Source RTP Stream" as >> defined by [RFC7656] Section 2.1.10. For Dependent Streams, it >> refers to the RTP Stream that, like the Source RTP Stream of an >> Encoded Stream, is the RTP Stream that is not a Redundancy RTP >> Stream. For conciseness, we define the term "RID RTP Stream" to >> refer to this construct. >> >> I think this definition is not correct. From my perspective it might >> be better to talk about the RTP stream produced by the media >> packetizer from a encoded or set of dependent streams. I write a set >> of dependent stream as on RTP stream can be produced by packetizing >> multiple dependent streams in the same. This would occur if one is not >> producing different RTP streams for all produced scalability layers. >> >> However, the main issue is that the definition does not correctly >> identifies what the RID refers to. To my understanding the RID refers >> to one RTP stream [A] packetized from either one encoded stream and >> zero or more dependent streams, or one or more dependent streams and >> the one or more redundancy streams protecting the RTP stream [A]. > > For WebRTC simulcast, at least, this isn't what we need. If we have one > encoded stream and two dependent streams, this needs to result in three > RIDs (regardless of the presence or number of redundancy streams). > So there are some corner cases here, which is part of the issue. I agree that the most common case would be that a media encoder that produces one encoded stream and two dependent stream would in most cases be packetized as three different RTP streams. However, it is possible for some codecs to produce only one or two RTP streams from the above set of encoded and dependent streams. The following possibilities do exists: 1 RTP stream: Encoded stream + two dependent 2 RTP stream (alt A): First RTP stream = Encoded stream + dependent stream Second RTP stream = dependent stream 2 RTP stream (alt B): First RTP stream = Encoded stream Second RTP stream = both dependent stream These possibilities in the RTP packetization is one thing that complicates the definition of the RID aggregate definition. >> This also has the consequence that RID RTP Stream is not a suitable >> term as the RID identifies an possible aggregate of RTP streams, one >> source and zero or more redundancy RTP streams. > > We need some concise term here, and I don't care what it is. I would > personally be happy happy to change the term to "Spicy Mango Surprise" > if it got us to finished. I just want a well-defined term that means > exactly this construct. Yes, lets first talk about what RID actually should be, the aggregate of the source RTP stream and the redundnacy stream or for an individual RTP stream, then we can go back to what we call this. > >> 4. Section 3: >> >> For clarity, when RID is used, Redundancy RTP Streams that can be >> used to repair Received RTP Streams will use the same RID value as >> the Received RTP Stream they are intended to be combined with. If >> applications want to identify individual redundancy streams, they can >> add an RRID to them instead of or in addition to the RID. >> >> So the intention with RRID, is to identify Redundancy RTP streams. >> Considering that RID doesn't actually only represent the source RTP >> stream for the media, there is a mismatch. > > I'm confused. If I read the text you quoted above, it's pretty clear: > "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It > then builds a parallel construct for dependent streams, but these are > always going to have a different RID than their corresponding encoded > streams. So my understanding is that the RID actually represent the aggregate of the RTP source stream and the redundancy, from that perspective, term RTP stream Identifier is the wrong term. > > >> Also, the needs for RRID is also not clear, however, the basics of >> identifying the RTP stream only has the advantage of high likelihood >> of re-use in other mechanisms. > > This came out of discussions with Colin, which I interpreted as a > request to add a means to uniquely identify redundancy streams. The > *current* discussion seems to be leaning toward removing RRID, although > I'm waiting to hear from others on the topic still. Yes, so I agree with leaning to removing the RRID concept, because I think there is not a clear need at this point. At the same time I think RID as an aggregate is a bad construct, and would rather have RID to only name one particular RTP Stream, not an aggregate. > >> Some may protest, hey but we are loosing the coupling method between >> the source RTP stream and the Redundancy stream. Yes, I have a >> proposal below for how to resolve that, but at the same time, it is >> this coupling that creates the complicated definition of the RID SDES >> item. And this is actually quite a separate problem. One which has >> existed for some time, and may actually benefit from being taken on a >> separate work item. Especially as we may want to retrofit the outcome >> onto some existing mechanisms such as RTP Retransmission and Generic >> XOR FEC to enable single RTP session usage efficiently for both. >> >> So below is a possible solution if one desire to have a way of >> coupling the redundancy stream to the source RTP stream already in >> signalling and identifying it with the same properties as we get with >> RID for the Source RTP streams. >> >> The solution is simple, we simply have a=RID lines also for the >> Redundancy RTP streams. Then we define a new constraint which I will >> call "protect" which is a list of SIDs that points at one or more RTP >> streams for which this Redundancy RTP Stream is constrained to protect >> and provide redundancy for. > > We already had several rounds of discussion on this topic, and I made a > proposal that is functionally equivalent to what you're proposing. > > The problem that was raised is that making this change forces the WebRTC > API to expose multiple identifiers associated with a single WebRTC > construct. Basically, you can make the protocol slightly more > complicated and the API slightly simpler, or you can make the protocol > slightly simpler and the API slightly more complicated. There are a > couple of tie breakers here, both pointing to the API being simpler: (1) > the API is already defined and effectively frozen (WebRTC is trying to > get the document to stop changing so it can be published); and (2) the > priority of constituencies > (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) > prioritizes authors over implementors in protocol trade-offs, and this > calls for simplifying the API rather than the wire protocol. I recognize > that this is a W3C principle rather than an IETF principle, but it > remains sound advice in general. So I took a look at the W3C API where RID is mentioned and found the following definition in the current working draft: rid of type DOMString If set, this RTP encoding will be sent with the RID header extension as defined by [JSEP]. So, to my understanding the RID in the API only points to the source RTP stream. Thus I don't see a big issue with using a definition for RID is the ID for a single RTP stream. Then solving the redundancy stream binding using either of these two proposals: 1. Using a new RTP header extension that points on the source for the redundancy stream 2. Creating a new SDP RID constraint that allows a identified Redundancy stream to be bound in SDP to its source. I am currently thinking either of these proposals do work. > > >> 5. Section 4 and 6. >> >> What I am missing in this is a discussion of privacy and the potential >> for tracking the streams across an RTP system. This is usually fine, >> but may reveal things to a third party, thus their value should be >> protected towards third parties. > > If you can point me to similar language in another document for SSRC, > I'd be happy to copy it directly into this document. So there are some language in RFC 7022 on the CNAME. I note that CNAMES usually have more persistence across middlebox than RID has, as that is likely negotiated on per leg level. > >> The next part of this issue is the generation of these values should >> avoid leaking any information about the user and implementation. This >> leads to the question if the values should be using random values, >> with tag lengths as needed by the application. > > In practice, since these are scoped to the sending endpoint, I would > expect most implementations to use a very simple scheme, like a > single-character representation that starts with "0", works through "9", > and then steps up to "a" through "z", moving on to two-character > identifiers if they use more than 36 streams. > Yes, I fully agree. But there should be some warning or consideration that the assignment can actually reveal some information of which implementation is setting it. And in worst case if based on user details be a privacy issue. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 4 07:28: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 1945012D726 for ; Mon, 4 Apr 2016 07:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 N3tMxytcqU6G for ; Mon, 4 Apr 2016 07:28:06 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADD412D722 for ; Mon, 4 Apr 2016 07:28:05 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id e6so181761064vkh.2 for ; Mon, 04 Apr 2016 07:28:05 -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=n2SmiSHriRa2m34jYCTX9svDKxW8G9qQP1/d4IYyQWM=; b=FPSEs/7OAtduFuzkaWzkvz82D4LKThPnhjkaSQaCKgQNKOpsItHo4CYPfNZPa4lUNm LhH8EW8bAOEooewN1DWdP+M1dqr6Hp8nnMtiYbS5mdydsiETNmOF4u2SAXj3AetToiuK ULc/VwvQCAvXlCqD3N0BzYk/YDT1f6K5wtqs3Ard2oZ66zr19wWSEX4MlQX6yxOw69Hy zRO8tFkKSaWrM3npysFnLaPda3fZVdwDrk6BKJIah0aK5MKrnUk/wSxAFD4d/57f14ad rGsSCLCrcq8O9nDqKB8cVvTM3mPzPCxr/ndSYRyk6kmu8VOyDoiVIPYA8gpW/uG24wOX qm3A== 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=n2SmiSHriRa2m34jYCTX9svDKxW8G9qQP1/d4IYyQWM=; b=CxqDurc6WOBmv/OtChG8p//Fk+6+dLo5M9eYdrx09OtdzOzEZ6vKqzT65Bi2+q7l2P SRM9Hei11oel6LUYkRL33uXyAnjbfbGzeagxgbN2APPee6v3KpEGaarV9wMJk3hq9Pzf e3Dcq0Jrl+DzeZMbwrSe3wPqxPwyk6Z3QGDkYm+4V9mgEunLs3OvwNj/ySYVLAEq5Ecj bglGXjEPBscKy4zVUoOdjWDT/Jq1aFrzKUNAb5jJiWoPiRNUxawW0JyTQBc0asMmhg3Z 6vhzkK+fTFw6llP2ZpfYZtmLzUsoABtM7LJJs5dJjYgJZppcukU0VfOr0GDTgL93/VGt Efog== X-Gm-Message-State: AD7BkJLf4mhKITGPu6XCxkwTKv0RERfGU4jppI1NC+e1CLoY1b2R2HLYojRrfsrImSPq2CxXwXFkjNvwnztj3Qa3 X-Received: by 10.176.6.4 with SMTP id f4mr9576770uaf.95.1459780084941; Mon, 04 Apr 2016 07:28:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 4 Apr 2016 07:27:25 -0700 (PDT) In-Reply-To: <6C748B18-125E-4C0F-9FB9-70169AC9F888@csperkins.org> References: <56FD3492.8080600@ericsson.com> <57012FC5.7040705@nostrum.com> <6C748B18-125E-4C0F-9FB9-70169AC9F888@csperkins.org> From: Peter Thatcher Date: Mon, 4 Apr 2016 07:27:25 -0700 Message-ID: To: Colin Perkins Content-Type: multipart/alternative; boundary=94eb2c048cb46a2057052fa9897f Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:28:10 -0000 --94eb2c048cb46a2057052fa9897f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 4, 2016 at 3:28 AM, Colin Perkins wrote: > > > On 3 Apr 2016, at 15:59, Adam Roach wrote: > > > > On 3/31/16 11:30, Magnus Westerlund wrote: > >> Hi, > >> > >> Here are my comments on the draft-ietf-avtext-rid-01. I think it is > very good that we have an upcoming meeting where we can discuss the below > issues. > >> > >> 1. Abstract: > >> > >> This document defines and registers an RTCP SDES item, RID, for > >> identification of RTP streams associated with Encoded Streams and > >> Dependent Streams. > >> > >> Should this really use plural of RTP streams as well as Encoded > Streams. A particular RID value is the identifier for one Encoded or > Dependent Stream in its RTP packetized form plus. Thus I think this > abstract could be clearer. However, I think it may need to addressed > anyway based on comment 3 and 4. > > > > No; grammatically, what's in there makes sense. It might not be as > obvious because we're talking about abstract concepts rather than concret= e > nouns, but this sentence is grammatically parallel to "This document > defines and registers a metal label, called a "license plate", for > identification of cars associated with drivers and passengers." (Yes, thi= s > isn't what license plates do, but I'm clarifying the grammatical structur= e, > not the meaning). > > > > > >> > >> 2. Section 1: > >> > >> RTP sessions frequently consist of multiple streams, each of which is > >> identified at any given time by its SSRC; however, the SSRC > >> associated with a stream is not guaranteed to be stable over its > >> lifetime. Within a session, these streams can be tagged with a > >> number of identifiers, including CNAMEs and MSIDs > >> [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the prope= r > >> ordinality to refer to an individual stream; all such identifiers ca= n > >> appear in more than one stream at a time. While approaches that use > >> unique Payload Types (PTs) per stream have been used in some > >> applications, > >> > >> I think the usage of Stream should at least on the first usage say "RT= P > Stream" and with a reference to RFC7656 to make it clear what entity you > are discussing in this paragraph. > > > > How about "RTP sessions frequently consist of mutiple RTP streams (see > section 3), each of which..."? > > > > > >> 3. Section 3: > >> > >> For Encoded Streams, the RID refers to the "Source RTP Stream" as > >> defined by [RFC7656] Section 2.1.10. For Dependent Streams, it > >> refers to the RTP Stream that, like the Source RTP Stream of an > >> Encoded Stream, is the RTP Stream that is not a Redundancy RTP > >> Stream. For conciseness, we define the term "RID RTP Stream" to > >> refer to this construct. > >> > >> I think this definition is not correct. From my perspective it might b= e > better to talk about the RTP stream produced by the media packetizer from= a > encoded or set of dependent streams. I write a set of dependent stream as > on RTP stream can be produced by packetizing multiple dependent streams i= n > the same. This would occur if one is not producing different RTP streams > for all produced scalability layers. > >> > >> However, the main issue is that the definition does not correctly > identifies what the RID refers to. To my understanding the RID refers to > one RTP stream [A] packetized from either one encoded stream and zero or > more dependent streams, or one or more dependent streams and the one or > more redundancy streams protecting the RTP stream [A]. > > > > For WebRTC simulcast, at least, this isn't what we need. If we have one > encoded stream and two dependent streams, this needs to result in three > RIDs (regardless of the presence or number of redundancy streams). > > > >> This also has the consequence that RID RTP Stream is not a suitable > term as the RID identifies an possible aggregate of RTP streams, one sour= ce > and zero or more redundancy RTP streams. > > > > We need some concise term here, and I don't care what it is. I would > personally be happy happy to change the term to "Spicy Mango Surprise" if > it got us to finished. I just want a well-defined term that means exactly > this construct. > > > >> 4. Section 3: > >> > >> For clarity, when RID is used, Redundancy RTP Streams that can be > >> used to repair Received RTP Streams will use the same RID value as > >> the Received RTP Stream they are intended to be combined with. If > >> applications want to identify individual redundancy streams, they ca= n > >> add an RRID to them instead of or in addition to the RID. > >> > >> So the intention with RRID, is to identify Redundancy RTP streams. > Considering that RID doesn't actually only represent the source RTP strea= m > for the media, there is a mismatch. > > > > I'm confused. If I read the text you quoted above, it's pretty clear: > "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It then > builds a parallel construct for dependent streams, but these are always > going to have a different RID than their corresponding encoded streams. > > > > > >> Also, the needs for RRID is also not clear, however, the basics of > identifying the RTP stream only has the advantage of high likelihood of > re-use in other mechanisms. > > > > This came out of discussions with Colin, which I interpreted as a > request to add a means to uniquely identify redundancy streams. > > I suggested that, if RID is being used, every RTP stream in an RTP sessio= n > needs to have a unique RID. > > =E2=80=8BThat's what Magnus is calling "SID", so let's stick with that name= to avoid confusion.=E2=80=8B =E2=80=8B > A consequence of that would be that a redundant RTP stream would have a > different RID to the original RTP stream. However, that would be true of > any two RTP streams. > > > The *current* discussion seems to be leaning toward removing RRID, > although I=E2=80=99m waiting to hear from others on the topic still. > > I don=E2=80=99t see value in the RRID as specified. > > I do see value in defining an =E2=80=9Cassociated RID=E2=80=9D header ext= ension. That > would be a field that indicates a stream associated with the current > stream. For example, if the main RTP stream had RID=3DXXX and the redunda= nt > RTP stream had RID=3DYYY, then the redundant RTP stream could also contai= n an > =E2=80=9Cassociated RID=E2=80=9D=3DXXX header, to indicate which stream i= t is providing > redundancy for. This is similar to Magnus=E2=80=99 current proposal (and = the > arguments for-and-against it were similar). > =E2=80=8BThat's what RID is, basically. It's the way for the Redundancy RT= P Stream to refer to the non-Redundancy RTP Stream. =E2=80=8B > Colin > > > > >> Some may protest, hey but we are loosing the coupling method between > the source RTP stream and the Redundancy stream. Yes, I have a proposal > below for how to resolve that, but at the same time, it is this coupling > that creates the complicated definition of the RID SDES item. And this is > actually quite a separate problem. One which has existed for some time, a= nd > may actually benefit from being taken on a separate work item. Especially > as we may want to retrofit the outcome onto some existing mechanisms such > as RTP Retransmission and Generic XOR FEC to enable single RTP session > usage efficiently for both. > >> > >> So below is a possible solution if one desire to have a way of couplin= g > the redundancy stream to the source RTP stream already in signalling and > identifying it with the same properties as we get with RID for the Source > RTP streams. > >> > >> The solution is simple, we simply have a=3DRID lines also for the > Redundancy RTP streams. Then we define a new constraint which I will call > "protect" which is a list of SIDs that points at one or more RTP streams > for which this Redundancy RTP Stream is constrained to protect and provid= e > redundancy for. > > > > We already had several rounds of discussion on this topic, and I made a > proposal that is functionally equivalent to what you're proposing. > > > > The problem that was raised is that making this change forces the WebRT= C > API to expose multiple identifiers associated with a single WebRTC > construct. Basically, you can make the protocol slightly more complicated > and the API slightly simpler, or you can make the protocol slightly simpl= er > and the API slightly more complicated. There are a couple of tie breakers > here, both pointing to the API being simpler: (1) the API is already > defined and effectively frozen (WebRTC is trying to get the document to > stop changing so it can be published); and (2) the priority of > constituencies ( > https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) > prioritizes authors over implementors in protocol trade-offs, and this > calls for simplifying the API rather than the wire protocol. I recognize > that this is a W3C principle rather than an IETF principle, but it remain= s > sound advice in general. > > > > > >> 5. Section 4 and 6. > >> > >> What I am missing in this is a discussion of privacy and the potential > for tracking the streams across an RTP system. This is usually fine, but > may reveal things to a third party, thus their value should be protected > towards third parties. > > > > If you can point me to similar language in another document for SSRC, > I'd be happy to copy it directly into this document. > > > >> The next part of this issue is the generation of these values should > avoid leaking any information about the user and implementation. This lea= ds > to the question if the values should be using random values, with tag > lengths as needed by the application. > > > > In practice, since these are scoped to the sending endpoint, I would > expect most implementations to use a very simple scheme, like a > single-character representation that starts with "0", works through "9", > and then steps up to "a" through "z", moving on to two-character > identifiers if they use more than 36 streams. > > > > /a > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > --94eb2c048cb46a2057052fa9897f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 3:28 AM, Colin Perkins <csp@csperkins.= org> wrote:

> On 3 Apr 2016, at 15:59, Adam Roach <adam@nostrum.com> wrote:
>
> On 3/31/16 11:30, Magnus Westerlund wrote:
>> Hi,
>>
>> Here are my comments on the draft-ietf-avtext-rid-01. I think it i= s very good that we have an upcoming meeting where we can discuss the below= issues.
>>
>> 1. Abstract:
>>
>>=C2=A0 =C2=A0This document defines and registers an RTCP SDES item,= RID, for
>>=C2=A0 =C2=A0identification of RTP streams associated with Encoded = Streams and
>>=C2=A0 =C2=A0Dependent Streams.
>>
>> Should this really use plural of RTP streams as well as Encoded St= reams. A particular RID value is the identifier for one Encoded or Dependen= t Stream in its RTP packetized form plus. Thus I think this abstract could = be clearer.=C2=A0 However, I think it may need to addressed anyway based on= comment 3 and 4.
>
> No; grammatically, what's in there makes sense. It might not be as= obvious because we're talking about abstract concepts rather than conc= rete nouns, but this sentence is grammatically parallel to "This docum= ent defines and registers a metal label, called a "license plate"= , for identification of cars associated with drivers and passengers." = (Yes, this isn't what license plates do, but I'm clarifying the gra= mmatical structure, not the meaning).
>
>
>>
>> 2. Section 1:
>>
>> RTP sessions frequently consist of multiple streams, each of which= is
>>=C2=A0 =C2=A0identified at any given time by its SSRC; however, the= SSRC
>>=C2=A0 =C2=A0associated with a stream is not guaranteed to be stabl= e over its
>>=C2=A0 =C2=A0lifetime.=C2=A0 Within a session, these streams can be= tagged with a
>>=C2=A0 =C2=A0number of identifiers, including CNAMEs and MSIDs
>>=C2=A0 =C2=A0[I-D.ietf-mmusic-msid].=C2=A0 Unfortunately, none of t= hese have the proper
>>=C2=A0 =C2=A0ordinality to refer to an individual stream; all such = identifiers can
>>=C2=A0 =C2=A0appear in more than one stream at a time.=C2=A0 While = approaches that use
>>=C2=A0 =C2=A0unique Payload Types (PTs) per stream have been used i= n some
>>=C2=A0 =C2=A0applications,
>>
>> I think the usage of Stream should at least on the first usage say= "RTP Stream" and with a reference to RFC7656 to make it clear wh= at entity you are discussing in this paragraph.
>
> How about "RTP sessions frequently consist of mutiple RTP streams= (see section 3), each of which..."?
>
>
>> 3. Section 3:
>>
>>=C2=A0 =C2=A0For Encoded Streams, the RID refers to the "Sourc= e RTP Stream" as
>>=C2=A0 =C2=A0defined by [RFC7656] Section 2.1.10.=C2=A0 For Depende= nt Streams, it
>>=C2=A0 =C2=A0refers to the RTP Stream that, like the Source RTP Str= eam of an
>>=C2=A0 =C2=A0Encoded Stream, is the RTP Stream that is not a Redund= ancy RTP
>>=C2=A0 =C2=A0Stream.=C2=A0 For conciseness, we define the term &quo= t;RID RTP Stream" to
>>=C2=A0 =C2=A0refer to this construct.
>>
>> I think this definition is not correct. From my perspective it mig= ht be better to talk about the RTP stream produced by the media packetizer = from a encoded or set of dependent streams. I write a set of dependent stre= am as on RTP stream can be produced by packetizing multiple dependent strea= ms in the same. This would occur if one is not producing different RTP stre= ams for all produced scalability layers.
>>
>> However, the main issue is that the definition does not correctly = identifies what the RID refers to. To my understanding the RID refers to on= e RTP stream [A] packetized from either one encoded stream and zero or more= dependent streams, or one or more dependent streams and the one or more re= dundancy streams protecting the RTP stream [A].
>
> For WebRTC simulcast, at least, this isn't what we need. If we hav= e one encoded stream and two dependent streams, this needs to result in thr= ee RIDs (regardless of the presence or number of redundancy streams).
>
>> This also has the consequence that RID RTP Stream is not a suitabl= e term as the RID identifies an possible aggregate of RTP streams, one sour= ce and zero or more redundancy RTP streams.
>
> We need some concise term here, and I don't care what it is. I wou= ld personally be happy happy to change the term to "Spicy Mango Surpri= se" if it got us to finished. I just want a well-defined term that mea= ns exactly this construct.
>
>> 4. Section 3:
>>
>>=C2=A0 =C2=A0For clarity, when RID is used, Redundancy RTP Streams = that can be
>>=C2=A0 =C2=A0used to repair Received RTP Streams will use the same = RID value as
>>=C2=A0 =C2=A0the Received RTP Stream they are intended to be combin= ed with. If
>>=C2=A0 =C2=A0applications want to identify individual redundancy st= reams, they can
>>=C2=A0 =C2=A0add an RRID to them instead of or in addition to the R= ID.
>>
>> So the intention with RRID, is to identify Redundancy RTP streams.= Considering that RID doesn't actually only represent the source RTP st= ream for the media, there is a mismatch.
>
> I'm confused. If I read the text you quoted above, it's pretty= clear: "For Encoded Streams, the RID refers to the 'Source RTP St= ream'". It then builds a parallel construct for dependent streams,= but these are always going to have a different RID than their correspondin= g encoded streams.
>
>
>> Also, the needs for RRID is also not clear, however, the basics of= identifying the RTP stream only has the advantage of high likelihood of re= -use in other mechanisms.
>
> This came out of discussions with Colin, which I interpreted as a requ= est to add a means to uniquely identify redundancy streams.

I suggested that, if RID is being used, every RTP stream in an = RTP session needs to have a unique RID.


=E2=80=8BThat's what Magnus is calling "SID&= quot;, so let's stick with that name to avoid confusion.=E2=80=8B
= =E2=80=8B

=C2=A0
A consequence of that would be that a redundant RTP stream would have a dif= ferent RID to the original RTP stream. However, that would be true of any t= wo RTP streams.

> The *current* discussion seems to be leaning toward removing RRID, alt= hough I=E2=80=99m waiting to hear from others on the topic still.

I don=E2=80=99t see value in the RRID as specified.

I do see value in defining an =E2=80=9Cassociated RID=E2=80=9D header exten= sion. That would be a field that indicates a stream associated with the cur= rent stream. For example, if the main RTP stream had RID=3DXXX and the redu= ndant RTP stream had RID=3DYYY, then the redundant RTP stream could also co= ntain an =E2=80=9Cassociated RID=E2=80=9D=3DXXX header, to indicate which s= tream it is providing redundancy for. This is similar to Magnus=E2=80=99 cu= rrent proposal (and the arguments for-and-against it were similar).

=E2=80=8BThat's what RID= is, basically.=C2=A0 It's the way for the Redundancy RTP Stream to ref= er to the non-Redundancy RTP Stream.
=E2=80=8B
Colin



>> Some may protest, hey but we are loosing the coupling method betwe= en the source RTP stream and the Redundancy stream. Yes, I have a proposal = below for how to resolve that, but at the same time, it is this coupling th= at creates the complicated definition of the RID SDES item. And this is act= ually quite a separate problem. One which has existed for some time, and ma= y actually benefit from being taken on a separate work item. Especially as = we may want to retrofit the outcome onto some existing mechanisms such as R= TP Retransmission and Generic XOR FEC to enable single RTP session usage ef= ficiently for both.
>>
>> So below is a possible solution if one desire to have a way of cou= pling the redundancy stream to the source RTP stream already in signalling = and identifying it with the same properties as we get with RID for the Sour= ce RTP streams.
>>
>> The solution is simple, we simply have a=3DRID lines also for the = Redundancy RTP streams. Then we define a new constraint which I will call &= quot;protect" which is a list of SIDs that points at one or more RTP s= treams for which this Redundancy RTP Stream is constrained to protect and p= rovide redundancy for.
>
> We already had several rounds of discussion on this topic, and I made = a proposal that is functionally equivalent to what you're proposing. >
> The problem that was raised is that making this change forces the WebR= TC API to expose multiple identifiers associated with a single WebRTC const= ruct. Basically, you can make the protocol slightly more complicated and th= e API slightly simpler, or you can make the protocol slightly simpler and t= he API slightly more complicated. There are a couple of tie breakers here, = both pointing to the API being simpler: (1) the API is already defined and = effectively frozen (WebRTC is trying to get the document to stop changing s= o it can be published); and (2) the priority of constituencies (https://www.w3.org/TR/html-design-princ= iples/#priority-of-constituencies) prioritizes authors over implementor= s in protocol trade-offs, and this calls for simplifying the API rather tha= n the wire protocol. I recognize that this is a W3C principle rather than a= n IETF principle, but it remains sound advice in general.
>
>
>> 5. Section 4 and 6.
>>
>> What I am missing in this is a discussion of privacy and the poten= tial for tracking the streams across an RTP system. This is usually fine, b= ut may reveal things to a third party, thus their value should be protected= towards third parties.
>
> If you can point me to similar language in another document for SSRC, = I'd be happy to copy it directly into this document.
>
>> The next part of this issue is the generation of these values shou= ld avoid leaking any information about the user and implementation. This le= ads to the question if the values should be using random values, with tag l= engths as needed by the application.
>
> In practice, since these are scoped to the sending endpoint, I would e= xpect most implementations to use a very simple scheme, like a single-chara= cter representation that starts with "0", works through "9&q= uot;, and then steps up to "a" through "z", moving on t= o two-character identifiers if they use more than 36 streams.
>
> /a
>
> _____________________________________= __________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext


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





--94eb2c048cb46a2057052fa9897f-- From nobody Mon Apr 4 07:30:36 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE43012D72D for ; Mon, 4 Apr 2016 07:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZRS7ytj4W6H7 for ; Mon, 4 Apr 2016 07:30:31 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD17F12D724 for ; Mon, 4 Apr 2016 07:30:28 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e6so181863950vkh.2 for ; Mon, 04 Apr 2016 07:30:28 -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=9r7RBE2gfURaKfwtW/bNdyjnGZV43+NKxA+eg0URrgQ=; b=mr+Z0MNzs0hDDfoUFfsNRKhEhApCwlrp1oYutRLFHZpvmobyEqT9tLGao+sMq+gsmi BSmtqAGLf0XU0MS9L2opYTIE31vdN4LgoIf9Wa4aaHrCBFOft2+tMV5wvV5NuOP14dbb lB+Kt5EIm8eSfMJi/4RuWlvNwlIyj13R4BgZApYqR1zzb04LZx2hPq37d0R9/oW8eK3s QO3gc1l0nH9tzC5kH4Cwhbk+xRy2aVsz5ilfndOa84NvARmHq3xuHu8NWgwwtd+9UaGj +HJcJ+9aH4reoydrdGoINnHVQnMxrTrcPePNILhtp30L1VjKwIaKeaLG1FEdm3DCq+mn CwpQ== 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=9r7RBE2gfURaKfwtW/bNdyjnGZV43+NKxA+eg0URrgQ=; b=IvudUEZUnyxpCd9IFDsj2dyLqNy7/SK2wBW0mjic+n/uDAx4qWK0AosGFxxPwEVU5t aGshF3xZlyeNoyapIRFN5IRTi1xyq7Joi5ZQo8/XirtglSaneDbHTLVz3gZs80TXnCAZ +99gfHWcBfE4J13J63265gOQzskClZ4+NWGgXukaNU9KnR4qhgVmwfBXe5SnAOJdG7hg gQjL81nLRqkGXWmB0NCz4FLMsN4R9iKVXlIHCvOzDIab+1ei3G/hs8emKghdt/sEyS1u 3FI/AgPJs3Vv4ZLGKWUEr5BWb69u829Eoz8zObxg3g9dkW4Ony2b+0V5iFPv/2IQRtMT UIAA== X-Gm-Message-State: AD7BkJKS6f1y5UZGgYzDLgdyTOSKLn4VvbG4FPB2yEk4S/PySTeUoWxl7g9f92fxhk81uSBUTK0rNguRHkLUm812 X-Received: by 10.31.137.17 with SMTP id l17mr6535955vkd.98.1459780227725; Mon, 04 Apr 2016 07:30:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 4 Apr 2016 07:29:48 -0700 (PDT) In-Reply-To: <5702797D.1020600@ericsson.com> References: <56FD3492.8080600@ericsson.com> <57012FC5.7040705@nostrum.com> <5702797D.1020600@ericsson.com> From: Peter Thatcher Date: Mon, 4 Apr 2016 07:29:48 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a114510feecceaa052fa99196 Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:30:35 -0000 --001a114510feecceaa052fa99196 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 4, 2016 at 7:26 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Please see inline. I think there are some clarifications needed here. > > > Den 2016-04-03 kl. 11:59, skrev Adam Roach: > >> On 3/31/16 11:30, Magnus Westerlund wrote: >> >>> Hi, >>> >>> Here are my comments on the draft-ietf-avtext-rid-01. I think it is >>> very good that we have an upcoming meeting where we can discuss the >>> below issues. >>> >>> 1. Abstract: >>> >>> This document defines and registers an RTCP SDES item, RID, for >>> identification of RTP streams associated with Encoded Streams and >>> Dependent Streams. >>> >>> Should this really use plural of RTP streams as well as Encoded >>> Streams. A particular RID value is the identifier for one Encoded or >>> Dependent Stream in its RTP packetized form plus. Thus I think this >>> abstract could be clearer. However, I think it may need to addressed >>> anyway based on comment 3 and 4. >>> >> >> No; grammatically, what's in there makes sense. It might not be as >> obvious because we're talking about abstract concepts rather than >> concrete nouns, but this sentence is grammatically parallel to "This >> document defines and registers a metal label, called a "license plate", >> for identification of cars associated with drivers and passengers." >> (Yes, this isn't what license plates do, but I'm clarifying the >> grammatical structure, not the meaning). >> >> > Ok > > >> >>> 2. Section 1: >>> >>> RTP sessions frequently consist of multiple streams, each of which is >>> identified at any given time by its SSRC; however, the SSRC >>> associated with a stream is not guaranteed to be stable over its >>> lifetime. Within a session, these streams can be tagged with a >>> number of identifiers, including CNAMEs and MSIDs >>> [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the prope= r >>> ordinality to refer to an individual stream; all such identifiers ca= n >>> appear in more than one stream at a time. While approaches that use >>> unique Payload Types (PTs) per stream have been used in some >>> applications, >>> >>> I think the usage of Stream should at least on the first usage say >>> "RTP Stream" and with a reference to RFC7656 to make it clear what >>> entity you are discussing in this paragraph. >>> >> >> How about "RTP sessions frequently consist of mutiple RTP streams (see >> section 3), each of which..."? >> >> > Yes, that is fine. > > >> 3. Section 3: >>> >>> For Encoded Streams, the RID refers to the "Source RTP Stream" as >>> defined by [RFC7656] Section 2.1.10. For Dependent Streams, it >>> refers to the RTP Stream that, like the Source RTP Stream of an >>> Encoded Stream, is the RTP Stream that is not a Redundancy RTP >>> Stream. For conciseness, we define the term "RID RTP Stream" to >>> refer to this construct. >>> >>> I think this definition is not correct. From my perspective it might >>> be better to talk about the RTP stream produced by the media >>> packetizer from a encoded or set of dependent streams. I write a set >>> of dependent stream as on RTP stream can be produced by packetizing >>> multiple dependent streams in the same. This would occur if one is not >>> producing different RTP streams for all produced scalability layers. >>> >>> However, the main issue is that the definition does not correctly >>> identifies what the RID refers to. To my understanding the RID refers >>> to one RTP stream [A] packetized from either one encoded stream and >>> zero or more dependent streams, or one or more dependent streams and >>> the one or more redundancy streams protecting the RTP stream [A]. >>> >> >> For WebRTC simulcast, at least, this isn't what we need. If we have one >> encoded stream and two dependent streams, this needs to result in three >> RIDs (regardless of the presence or number of redundancy streams). >> >> > So there are some corner cases here, which is part of the issue. I agree > that the most common case would be that a media encoder that produces one > encoded stream and two dependent stream would in most cases be packetized > as three different RTP streams. However, it is possible for some codecs t= o > produce only one or two RTP streams from the above set of encoded and > dependent streams. The following possibilities do exists: > > 1 RTP stream: Encoded stream + two dependent > 2 RTP stream (alt A): > First RTP stream =3D Encoded stream + dependent stream > Second RTP stream =3D dependent stream > 2 RTP stream (alt B): > First RTP stream =3D Encoded stream > Second RTP stream =3D both dependent stream > > These possibilities in the RTP packetization is one thing that complicate= s > the definition of the RID aggregate definition. > > This also has the consequence that RID RTP Stream is not a suitable >>> term as the RID identifies an possible aggregate of RTP streams, one >>> source and zero or more redundancy RTP streams. >>> >> >> We need some concise term here, and I don't care what it is. I would >> personally be happy happy to change the term to "Spicy Mango Surprise" >> if it got us to finished. I just want a well-defined term that means >> exactly this construct. >> > > Yes, lets first talk about what RID actually should be, the aggregate of > the source RTP stream and the redundnacy stream or for an individual RTP > stream, then we can go back to what we call this. > > >> 4. Section 3: >>> >>> For clarity, when RID is used, Redundancy RTP Streams that can be >>> used to repair Received RTP Streams will use the same RID value as >>> the Received RTP Stream they are intended to be combined with. If >>> applications want to identify individual redundancy streams, they ca= n >>> add an RRID to them instead of or in addition to the RID. >>> >>> So the intention with RRID, is to identify Redundancy RTP streams. >>> Considering that RID doesn't actually only represent the source RTP >>> stream for the media, there is a mismatch. >>> >> >> I'm confused. If I read the text you quoted above, it's pretty clear: >> "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It >> then builds a parallel construct for dependent streams, but these are >> always going to have a different RID than their corresponding encoded >> streams. >> > > So my understanding is that the RID actually represent the aggregate of > the RTP source stream and the redundancy, from that perspective, term RTP > stream Identifier is the wrong term. =E2=80=8BNo, it does not represent the aggregate. It represents one RTP St= ream. =E2=80=8B > > > >> >> Also, the needs for RRID is also not clear, however, the basics of >>> identifying the RTP stream only has the advantage of high likelihood >>> of re-use in other mechanisms. >>> >> >> This came out of discussions with Colin, which I interpreted as a >> request to add a means to uniquely identify redundancy streams. The >> *current* discussion seems to be leaning toward removing RRID, although >> I'm waiting to hear from others on the topic still. >> > > Yes, so I agree with leaning to removing the RRID concept, because I thin= k > there is not a clear need at this point. At the same time I think RID as = an > aggregate is a bad construct, and would rather have RID to only name one > particular RTP Stream, not an aggregate. =E2=80=8BIt's not an aggregate. =E2=80=8B > > > >> Some may protest, hey but we are loosing the coupling method between >>> the source RTP stream and the Redundancy stream. Yes, I have a >>> proposal below for how to resolve that, but at the same time, it is >>> this coupling that creates the complicated definition of the RID SDES >>> item. And this is actually quite a separate problem. One which has >>> existed for some time, and may actually benefit from being taken on a >>> separate work item. Especially as we may want to retrofit the outcome >>> onto some existing mechanisms such as RTP Retransmission and Generic >>> XOR FEC to enable single RTP session usage efficiently for both. >>> >>> So below is a possible solution if one desire to have a way of >>> coupling the redundancy stream to the source RTP stream already in >>> signalling and identifying it with the same properties as we get with >>> RID for the Source RTP streams. >>> >>> The solution is simple, we simply have a=3DRID lines also for the >>> Redundancy RTP streams. Then we define a new constraint which I will >>> call "protect" which is a list of SIDs that points at one or more RTP >>> streams for which this Redundancy RTP Stream is constrained to protect >>> and provide redundancy for. >>> >> >> We already had several rounds of discussion on this topic, and I made a >> proposal that is functionally equivalent to what you're proposing. >> >> The problem that was raised is that making this change forces the WebRTC >> API to expose multiple identifiers associated with a single WebRTC >> construct. Basically, you can make the protocol slightly more >> complicated and the API slightly simpler, or you can make the protocol >> slightly simpler and the API slightly more complicated. There are a >> couple of tie breakers here, both pointing to the API being simpler: (1) >> the API is already defined and effectively frozen (WebRTC is trying to >> get the document to stop changing so it can be published); and (2) the >> priority of constituencies >> (https://www.w3.org/TR/html-design-principles/#priority-of-constituencie= s >> ) >> prioritizes authors over implementors in protocol trade-offs, and this >> calls for simplifying the API rather than the wire protocol. I recognize >> that this is a W3C principle rather than an IETF principle, but it >> remains sound advice in general. >> > > So I took a look at the W3C API where RID is mentioned and found the > following definition in the current working draft: > > rid of type DOMString > > If set, this RTP encoding will be sent with the RID header > extension as defined by [JSEP]. > > So, to my understanding the RID in the API only points to the source RTP > stream. > > Thus I don't see a big issue with using a definition for RID is the ID fo= r > a single RTP stream. Then solving the redundancy stream binding using > either of these two proposals: > =E2=80=8BThat's what it is: one RTP Stream.=E2=80=8B > > 1. Using a new RTP header extension that points on the source for the > redundancy stream > > 2. Creating a new SDP RID constraint that allows a identified Redundancy > stream to be bound in SDP to its source. > > I am currently thinking either of these proposals do work. > > > >> >> 5. Section 4 and 6. >>> >>> What I am missing in this is a discussion of privacy and the potential >>> for tracking the streams across an RTP system. This is usually fine, >>> but may reveal things to a third party, thus their value should be >>> protected towards third parties. >>> >> >> If you can point me to similar language in another document for SSRC, >> I'd be happy to copy it directly into this document. >> > > So there are some language in RFC 7022 on the CNAME. I note that CNAMES > usually have more persistence across middlebox than RID has, as that is > likely negotiated on per leg level. > > >> The next part of this issue is the generation of these values should >>> avoid leaking any information about the user and implementation. This >>> leads to the question if the values should be using random values, >>> with tag lengths as needed by the application. >>> >> >> In practice, since these are scoped to the sending endpoint, I would >> expect most implementations to use a very simple scheme, like a >> single-character representation that starts with "0", works through "9", >> and then steps up to "a" through "z", moving on to two-character >> identifiers if they use more than 36 streams. >> >> > Yes, I fully agree. But there should be some warning or consideration tha= t > the assignment can actually reveal some information of which implementati= on > is setting it. And in worst case if based on user details be a privacy > issue. > > > 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 > ---------------------------------------------------------------------- > > --001a114510feecceaa052fa99196 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Apr 4, 2016 at 7:26 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

Please see inline. I think there are some clarifications needed here.


Den 2016-04-03 kl. 11:59, skrev Adam Roach:
On 3/31/16 11:30, Magnus Westerlund wrote:
Hi,

Here are my comments on the draft-ietf-avtext-rid-01. I think it is
very good that we have an upcoming meeting where we can discuss the
below issues.

1. Abstract:

=C2=A0 =C2=A0This document defines and registers an RTCP SDES item, RID, fo= r
=C2=A0 =C2=A0identification of RTP streams associated with Encoded Streams = and
=C2=A0 =C2=A0Dependent Streams.

Should this really use plural of RTP streams as well as Encoded
Streams. A particular RID value is the identifier for one Encoded or
Dependent Stream in its RTP packetized form plus. Thus I think this
abstract could be clearer.=C2=A0 However, I think it may need to addressed<= br> anyway based on comment 3 and 4.

No; grammatically, what's in there makes sense. It might not be as
obvious because we're talking about abstract concepts rather than
concrete nouns, but this sentence is grammatically parallel to "This document defines and registers a metal label, called a "license plate&= quot;,
for identification of cars associated with drivers and passengers." (Yes, this isn't what license plates do, but I'm clarifying the
grammatical structure, not the meaning).


 Ok



2. Section 1:

RTP sessions frequently consist of multiple streams, each of which is
=C2=A0 =C2=A0identified at any given time by its SSRC; however, the SSRC =C2=A0 =C2=A0associated with a stream is not guaranteed to be stable over i= ts
=C2=A0 =C2=A0lifetime.=C2=A0 Within a session, these streams can be tagged = with a
=C2=A0 =C2=A0number of identifiers, including CNAMEs and MSIDs
=C2=A0 =C2=A0[I-D.ietf-mmusic-msid].=C2=A0 Unfortunately, none of these hav= e the proper
=C2=A0 =C2=A0ordinality to refer to an individual stream; all such identifi= ers can
=C2=A0 =C2=A0appear in more than one stream at a time.=C2=A0 While approach= es that use
=C2=A0 =C2=A0unique Payload Types (PTs) per stream have been used in some =C2=A0 =C2=A0applications,

I think the usage of Stream should at least on the first usage say
"RTP Stream" and with a reference to RFC7656 to make it clear wha= t
entity you are discussing in this paragraph.

How about "RTP sessions frequently consist of mutiple RTP streams (see=
section 3), each of which..."?


 Yes, that is fine.


3. Section 3:

=C2=A0 =C2=A0For Encoded Streams, the RID refers to the "Source RTP St= ream" as
=C2=A0 =C2=A0defined by [RFC7656] Section 2.1.10.=C2=A0 For Dependent Strea= ms, it
=C2=A0 =C2=A0refers to the RTP Stream that, like the Source RTP Stream of a= n
=C2=A0 =C2=A0Encoded Stream, is the RTP Stream that is not a Redundancy RTP=
=C2=A0 =C2=A0Stream.=C2=A0 For conciseness, we define the term "RID RT= P Stream" to
=C2=A0 =C2=A0refer to this construct.

I think this definition is not correct. From my perspective it might
be better to talk about the RTP stream produced by the media
packetizer from a encoded or set of dependent streams. I write a set
of dependent stream as on RTP stream can be produced by packetizing
multiple dependent streams in the same. This would occur if one is not
producing different RTP streams for all produced scalability layers.

However, the main issue is that the definition does not correctly
identifies what the RID refers to. To my understanding the RID refers
to one RTP stream [A] packetized from either one encoded stream and
zero or more dependent streams, or one or more dependent streams and
the one or more redundancy streams protecting the RTP stream [A].

For WebRTC simulcast, at least, this isn't what we need. If we have one=
encoded stream and two dependent streams, this needs to result in three
RIDs (regardless of the presence or number of redundancy streams).


 So there are some corner cases here, which is part of the issue. I agree th= at the most common case would be that a media encoder that produces one enc= oded stream and two dependent stream would in most cases be packetized as t= hree different RTP streams. However, it is possible for some codecs to prod= uce only one or two RTP streams from the above set of encoded and dependent= streams. The following possibilities do exists:

1 RTP stream: Encoded stream + two dependent
2 RTP stream (alt A):
=C2=A0 =C2=A0 First RTP stream =3D Encoded stream + dependent stream
=C2=A0 =C2=A0 Second RTP stream =3D dependent stream
2 RTP stream (alt B):
=C2=A0 =C2=A0First RTP stream =3D Encoded stream
=C2=A0 =C2=A0Second RTP stream =3D both dependent stream

These possibilities in the RTP packetization is one thing that complicates = the definition of the RID aggregate definition.

This also has the consequence that RID RTP Stream is not a suitable
term as the RID identifies an possible aggregate of RTP streams, one
source and zero or more redundancy RTP streams.

We need some concise term here, and I don't care what it is. I would personally be happy happy to change the term to "Spicy Mango Surprise&= quot;
if it got us to finished. I just want a well-defined term that means
exactly this construct.

 Yes, lets first talk about what RID actually should be, the aggregate of th= e source RTP stream and the redundnacy stream or for an individual RTP stre= am, then we can go back to what we call this.


4. Section 3:

=C2=A0 =C2=A0For clarity, when RID is used, Redundancy RTP Streams that can= be
=C2=A0 =C2=A0used to repair Received RTP Streams will use the same RID valu= e as
=C2=A0 =C2=A0the Received RTP Stream they are intended to be combined with.= If
=C2=A0 =C2=A0applications want to identify individual redundancy streams, t= hey can
=C2=A0 =C2=A0add an RRID to them instead of or in addition to the RID.

So the intention with RRID, is to identify Redundancy RTP streams.
Considering that RID doesn't actually only represent the source RTP
stream for the media, there is a mismatch.

I'm confused. If I read the text you quoted above, it's pretty clea= r:
"For Encoded Streams, the RID refers to the 'Source RTP Stream'= ;". It
then builds a parallel construct for dependent streams, but these are
always going to have a different RID than their corresponding encoded
streams.

 So my understanding is that the RID actually represent the aggregate of the= RTP source stream and the redundancy, from that perspective, term RTP stre= am Identifier is the wrong term.

=E2=80= =8BNo, it does not represent the aggregate.=C2=A0 It represents one RTP Str= eam. =C2=A0=E2=80=8B

=C2=A0




Also, the needs for RRID is also not clear, however, the basics of
identifying the RTP stream only has the advantage of high likelihood
of re-use in other mechanisms.

This came out of discussions with Colin, which I interpreted as a
request to add a means to uniquely identify redundancy streams. The
*current* discussion seems to be leaning toward removing RRID, although
I'm waiting to hear from others on the topic still.

 Yes, so I agree with leaning to removing the RRID concept, because I think = there is not a clear need at this point. At the same time I think RID as an= aggregate is a bad construct, and would rather have RID to only name one p= articular RTP Stream, not an aggregate.

=E2=80=8BIt's not an aggregate.
=E2=80=8B
=C2=A0



Some may protest, hey but we are loosing the coupling method between
the source RTP stream and the Redundancy stream. Yes, I have a
proposal below for how to resolve that, but at the same time, it is
this coupling that creates the complicated definition of the RID SDES
item. And this is actually quite a separate problem. One which has
existed for some time, and may actually benefit from being taken on a
separate work item. Especially as we may want to retrofit the outcome
onto some existing mechanisms such as RTP Retransmission and Generic
XOR FEC to enable single RTP session usage efficiently for both.

So below is a possible solution if one desire to have a way of
coupling the redundancy stream to the source RTP stream already in
signalling and identifying it with the same properties as we get with
RID for the Source RTP streams.

The solution is simple, we simply have a=3DRID lines also for the
Redundancy RTP streams. Then we define a new constraint which I will
call "protect" which is a list of SIDs that points at one or more= RTP
streams for which this Redundancy RTP Stream is constrained to protect
and provide redundancy for.

We already had several rounds of discussion on this topic, and I made a
proposal that is functionally equivalent to what you're proposing.

The problem that was raised is that making this change forces the WebRTC API to expose multiple identifiers associated with a single WebRTC
construct. Basically, you can make the protocol slightly more
complicated and the API slightly simpler, or you can make the protocol
slightly simpler and the API slightly more complicated. There are a
couple of tie breakers here, both pointing to the API being simpler: (1) the API is already defined and effectively frozen (WebRTC is trying to
get the document to stop changing so it can be published); and (2) the
priority of constituencies
(https://www.w3.org/TR/html-= design-principles/#priority-of-constituencies)
prioritizes authors over implementors in protocol trade-offs, and this
calls for simplifying the API rather than the wire protocol. I recognize that this is a W3C principle rather than an IETF principle, but it
remains sound advice in general.

So I took a look at the W3C API where RID is mentioned and found the follow= ing definition in the current working draft:

rid of type DOMString

=C2=A0 =C2=A0 If set, this RTP encoding will be sent with the RID header =C2=A0 =C2=A0 extension as defined by [JSEP].

So, to my understanding the RID in the API only points to the source RTP st= ream.

Thus I don't see a big issue with using a definition for RID is the ID = for a single RTP stream. Then solving the redundancy stream binding using e= ither of these two proposals:

=E2=80= =8BThat's what it is: one RTP Stream.=E2=80=8B

=C2= =A0

1. Using a new RTP header extension that points on the source for the redun= dancy stream

2. Creating a new SDP RID constraint that allows a identified Redundancy st= ream to be bound in SDP to its source.

I am currently thinking either of these proposals do work.=




5. Section 4 and 6.

What I am missing in this is a discussion of privacy and the potential
for tracking the streams across an RTP system. This is usually fine,
but may reveal things to a third party, thus their value should be
protected towards third parties.

If you can point me to similar language in another document for SSRC,
I'd be happy to copy it directly into this document.

 So there are some language in RFC 7022 on the CNAME. I note that CNAMES usu= ally have more persistence across middlebox than RID has, as that is likely= negotiated on per leg level.


The next part of this issue is the generation of these values should
avoid leaking any information about the user and implementation. This
leads to the question if the values should be using random values,
with tag lengths as needed by the application.

In practice, since these are scoped to the sending endpoint, I would
expect most implementations to use a very simple scheme, like a
single-character representation that starts with "0", works throu= gh "9",
and then steps up to "a" through "z", moving on to two-= character
identifiers if they use more than 36 streams.


 Yes, I fully agree. But there should be some warning or consideration that = the assignment can actually reveal some information of which implementation= is setting it. And in worst case if based on user details be a privacy iss= ue.


Cheers

Magnus Westerlund

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


--001a114510feecceaa052fa99196-- From nobody Mon Apr 4 07:32: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 819DA12D109 for ; Mon, 4 Apr 2016 07:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 7EyAsQOwfPqQ for ; Mon, 4 Apr 2016 07:31:48 -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 9B0E312D719 for ; Mon, 4 Apr 2016 07:26:29 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id k1so181747994vkb.0 for ; Mon, 04 Apr 2016 07:26:29 -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=atsMhDQtQvIFeVo47VhWZ/mbqsHLTL57+mMwRQ5m+aY=; b=NvVkkLu7PV//AvjqB1kY8V0HdE6WCKIjZj+XSnns8uxa9BS+QSNoG9iHzdACCUsKWV C+JKXoGWN7hblOPmVYrWxTPC8kVux0drE3+lAS77lKvyhS7pEEyJuFH9A+9XYSaARDaI jLeqLEiXufQvkVQ+Q1DwyXyMpTOiUgVSg9IztxA3j2MDP5P+tKgZH8H2EhQTEOkNvCOJ WehkGZRVeMlfnrtqEtoHJfECQD9ZIHziCSYHJ1/MfR/Z2ZUv2OorFV66KYf6NAYn7Yxu 7LYq9gzfvBhVvYX0iYDGAOlvG/IgCisu3WLqGX/UtPHyUgwB+WoAkxDcEfv4uGWLcYtB dewg== 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=atsMhDQtQvIFeVo47VhWZ/mbqsHLTL57+mMwRQ5m+aY=; b=SwfxhdGvJoRTRoN69KPWZTaz0tiduiZdApp6CWK3iw6BjzDXSf1/KnutzCcqOk/W5G +/Q4HMs+lL+OEPpU9xI6n+lqpVXNDQWra76uPjuwyGI0XJ/egIy4lt8V4vUYZ9YwTDk/ 6wUc0cmr7ly7DT5dM6CUfwZEB/XXPIDkp1HVQ20K8CmwBXtuiA/pL3Woc3koMZTF6pco GwxMLzHRFNHlkE5+GlF57DbmkS2ZuayR3ce7nw42AB2qngDuO0NdLeBV9CVVgF8MxxEy CgzOX64ux/C1vvroMNyp3X8o3wiexZsTlmBSbZDsw71Yv4J0VLOwIkYTpFnzvWT5EuHq hS4w== X-Gm-Message-State: AD7BkJJL5tJzZ8VFWYWDQDZOPuLUZgdvA+peVuc7w+ttyqP1JJnOOV+2rUNdE2kP60RmPzLNJn18lByybu7e0n6H X-Received: by 10.176.3.17 with SMTP id 17mr4697594uat.35.1459779988578; Mon, 04 Apr 2016 07:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.133 with HTTP; Mon, 4 Apr 2016 07:25:48 -0700 (PDT) In-Reply-To: <56FD3492.8080600@ericsson.com> References: <56FD3492.8080600@ericsson.com> From: Peter Thatcher Date: Mon, 4 Apr 2016 07:25:48 -0700 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a113557a0abc67e052fa983c6 Archived-At: Cc: draft-ietf-avtext-rid@ietf.org, "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 14:31:51 -0000 --001a113557a0abc67e052fa983c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think you can get what you want by simply renaming RRID to SID and having the following definitions: SID =3D=3D "RTP Stream ID" RID =3D=3D "non-Redundancy RTP Stream ID" For a non-Redundancy RTP Stream, SID =3D=3D RID. On Thu, Mar 31, 2016 at 7:30 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Here are my comments on the draft-ietf-avtext-rid-01. I think it is very > good that we have an upcoming meeting where we can discuss the below issu= es. > > 1. Abstract: > > This document defines and registers an RTCP SDES item, RID, for > identification of RTP streams associated with Encoded Streams and > Dependent Streams. > > Should this really use plural of RTP streams as well as Encoded Streams. = A > particular RID value is the identifier for one Encoded or Dependent Strea= m > in its RTP packetized form plus. Thus I think this abstract could be > clearer. However, I think it may need to addressed anyway based on comme= nt > 3 and 4. > =E2=80=8BThe RID, as written, does not identify an Encoded Stream or Depend= ent Stream. It identifies a non-Redundancy RTP stream. > > > > 2. Section 1: > > RTP sessions frequently consist of multiple streams, each of which is > identified at any given time by its SSRC; however, the SSRC > associated with a stream is not guaranteed to be stable over its > lifetime. Within a session, these streams can be tagged with a > number of identifiers, including CNAMEs and MSIDs > [I-D.ietf-mmusic-msid]. Unfortunately, none of these have the proper > ordinality to refer to an individual stream; all such identifiers can > appear in more than one stream at a time. While approaches that use > unique Payload Types (PTs) per stream have been used in some > applications, > > I think the usage of Stream should at least on the first usage say "RTP > Stream" and with a reference to RFC7656 to make it clear what entity you > are discussing in this paragraph. > 3. Section 3: > > For Encoded Streams, the RID refers to the "Source RTP Stream" as > defined by [RFC7656] Section 2.1.10. For Dependent Streams, it > refers to the RTP Stream that, like the Source RTP Stream of an > Encoded Stream, is the RTP Stream that is not a Redundancy RTP > Stream. For conciseness, we define the term "RID RTP Stream" to > refer to this construct. > > I think this definition is not correct. From my perspective it might be > better to talk about the RTP stream produced by the media packetizer from= a > encoded or set of dependent streams. I write a set of dependent stream as > on RTP stream can be produced by packetizing multiple dependent streams i= n > the same. This would occur if one is not producing different RTP streams > for all produced scalability layers. > > However, the main issue is that the definition does not correctly > identifies what the RID refers to. To my understanding the RID refers to > one RTP stream [A] packetized from either one encoded stream and zero or > more dependent streams, or one or more dependent streams and the one or > more redundancy streams protecting the RTP stream [A]. > The RID identifies an RTP stream that is not a Redundancy RTP Stream. =E2=80=8BT hat's all there is to it. =E2=80=8BAn Encoded Stream has one non-Redundancy RTP Stream called the Sou= rce RTP Stream. A RID refers to that RTP Stream. A Dependent Stream =E2=80=8B =E2=80=8B =E2=80=8Bhas one non-Redundancy RTP Stream which, exactly like the Encoded = Stream, but which doesn't have a name in the taxono=E2=80=8Bmy draft. Call it the "Dependent Source RTP Stream" if you like. A RID refers to that RTP Stream. > This also has the consequence that RID RTP Stream is not a suitable term > as the RID identifies an possible aggregate of RTP streams, one source an= d > zero or more redundancy RTP streams. > Since the RID only identifies one RTP Stream, it cannot be an aggregate stream, since a Source RTP Stream cannot be an aggregate of RTP streams. =E2=80=8B > > The above changed definition could be used, however I am not certain that > it is what we really like to use here. For that purpose see next comment. > > 4. Section 3: > > For clarity, when RID is used, Redundancy RTP Streams that can be > used to repair Received RTP Streams will use the same RID value as > the Received RTP Stream they are intended to be combined with. If > applications want to identify individual redundancy streams, they can > add an RRID to them instead of or in addition to the RID. > > So the intention with RRID, is to identify Redundancy RTP streams. > Considering that RID doesn't actually only represent the source RTP strea= m > for the media, there is a mismatch. The RID *does* identify the Source RTP Stream (or the unnamed equivalent of =E2=80=8Ba Dependent Stream). The RID identifies a non-Redudancy RTP Stream. The RRID identifies a Redundancy RTP Stream. Also, the needs for RRID is also not clear, however, the basics of > identifying the RTP stream only has the advantage of high likelihood of > re-use in other mechanisms. > =E2=80=8BI don't see the need either, but Colin asked for it. =E2=80=8B > > However, I would like to take a collected consideration of the RID and > RRID definitions and actually propose that we change the RID definition. = To > be clear on that this is another definition this new identifier I will > refer to as RTP Stream IDentifier (SID). > > The definition of SID would be: "An identifier for a single RTP stream." > =E2=80=8BThat's basically what RRID is. We even considered calling it SID,= I believe. For a non-Redundancy RTP Stream, an RRID =3D=3D RID, so it would = just use RID and not RRID. > > This of course have implication on the RID mechanism expressing the > payload format constraints. However, I think it fulfil the basic needs ve= ry > nicely. The a=3Drid lines points at a SID for which is the RTP stream for > which the set of constraints apply. > =E2=80=8BIf an "a=3Drid' line points to a SID and not a RID, I think we've = be just confusing ourselves way more than we need to. But since RID=3D=3DSID for a non-Redundancy RTP Stream, it doesn't matter. > This is the basic part of the RID proposal. And this removes the need for > RRID, as also Redundancy RTP streams can have a SID, if needed by the > application. We get a generic basic identification that is likely to be > re-usable while solving the current needs. > =E2=80=8BAt that point, you've basically just renamed RRID to SID. =E2=80= =8B The real question, though, is what goes in the header extension of the Redundancy RTP Stream. The whole point of RIDs in the first place is to allow the Redundancy RTP Stream to refer to the non-Redundancy RTP Stream. Referring to itself is useless. So we still need a header extension that means "The ID of the non-Redundancy RTP Stream". We have a few options for doing so: Option A (current draft): non-Redundancy referring to self: RID Redundancy Refererring to self: RRID Redundancy Referring to non-Redundancy: RID Option B (your proposal): non-Redundancy referring to self: SID Redundancy Refererring to self: SID Redundancy Referring to non-Redundancy: ??? Option C=E2=80=8B non-Redundancy referring to self: SID or RID (either way!) Redundancy Refererring to self: SID Redundancy Referring to non-Redundancy: RID I'd be happy with Option C, as long as the header extension allows the Redundancy RTP Stream to include the RID and not the SID of itself. =E2=80=8B =E2=80=8B > > Some may protest, hey but we are loosing the coupling method between the > source RTP stream and the Redundancy stream. Yes, I have a proposal below > for how to resolve that, but at the same time, it is this coupling that > creates the complicated definition of the RID SDES item. And this is > actually quite a separate problem. One which has existed for some time, a= nd > may actually benefit from being taken on a separate work item. Especially > as we may want to retrofit the outcome onto some existing mechanisms such > as RTP Retransmission and Generic XOR FEC to enable single RTP session > usage efficiently for both. > > So below is a possible solution if one desire to have a way of coupling > the redundancy stream to the source RTP stream already in signalling and > identifying it with the same properties as we get with RID for the Source > RTP streams. > > The solution is simple, we simply have a=3DRID lines also for the Redunda= ncy > RTP streams. Then we define a new constraint which I will call "protect" > which is a list of SIDs that points at one or more RTP streams for which > this Redundancy RTP Stream is constrained to protect and provide redundan= cy > for. > =E2=80=8B No, no, no. There is no need for requiring this to be signalled, or for this to be in SDP. That's just useless complexity. I'm fine with renaming RRID to SID and tweaking the definition, but I'm not OK with adding a bunch of SDP complexity where we don't need it. > > An basic SDP example for this would be the following: > > m=3Dvideo 10000 RTP/SAVPF 100 101 108 109 > a=3Drtpmap:100 H264/90000 > a=3Dfmtp:100 profile-level-id=3D42401f; packetization-mode=3D0 > a=3Drtpmap:101 H264/90000 > a=3Dfmtp:101 profile-level-id=3D42401f; packetization-mode=3D1 > a=3Drtpmap:108 rtx/90000 > a=3Dfmtp:108 apt=3D100 > a=3Drtpmap:109 rtx/90000 > a=3Dfmtp:109 apt=3D101 > a=3Dsendrecv > a=3Dmid:v1 (max resolution) > a=3Drid:1 send max-width=3D1280;max-height=3D720;max-fps=3D30 > a=3Drid:2 recv max-width=3D1280;max-height=3D720;max-fps=3D30 > a=3Drid:A send pt=3D108,109;protect=3D1 > a=3Drid:B recv pt=3D108,109;protect=3D2 > > So at RTP session startup when the offerer of the above starts sending it > will send two RTP streams from the above block. One for the video using > SID=3D1 and another for the RTX packets using SID=3DA. > > > 5. Section 4 and 6. > > What I am missing in this is a discussion of privacy and the potential fo= r > tracking the streams across an RTP system. This is usually fine, but may > reveal things to a third party, thus their value should be protected > towards third parties. > > The next part of this issue is the generation of these values should avoi= d > leaking any information about the user and implementation. This leads to > the question if the values should be using random values, with tag length= s > as needed by the application. > > > 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 > ---------------------------------------------------------------------- > > --001a113557a0abc67e052fa983c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think you can get what you want by simply renaming RR= ID to SID and having the following definitions:

SID = =3D=3D "RTP Stream ID"
RID =3D=3D "non-Redundancy RT= P Stream ID"

For a non-Redundancy RTP Stream, SID= =3D=3D RID.

On Thu, Mar 31, 2016 at 7:30 AM, Magnus Westerlund <<= a href=3D"mailto:magnus.westerlund@ericsson.com" target=3D"_blank">magnus.w= esterlund@ericsson.com> wrote:
Hi,

Here are my comments on the draft-ietf-avtext-rid-01. I think it is very go= od that we have an upcoming meeting where we can discuss the below issues.<= br>
1. Abstract:

=C2=A0 =C2=A0This document defines and registers an RTCP SDES item, RID, fo= r
=C2=A0 =C2=A0identification of RTP streams associated with Encoded Streams = and
=C2=A0 =C2=A0Dependent Streams.

Should this really use plural of RTP streams as well as Encoded Streams. A = particular RID value is the identifier for one Encoded or Dependent Stream = in its RTP packetized form plus. Thus I think this abstract could be cleare= r.=C2=A0 However, I think it may need to addressed anyway based on comment = 3 and 4.

=E2=80=8BThe RID, as written, does not identi= fy an Encoded Stream or Dependent Stream.=C2=A0 It identifies a non-Redunda= ncy RTP stream.



2. Section 1:

RTP sessions frequently consist of multiple streams, each of which is
=C2=A0 =C2=A0identified at any given time by its SSRC; however, the SSRC =C2=A0 =C2=A0associated with a stream is not guaranteed to be stable over i= ts
=C2=A0 =C2=A0lifetime.=C2=A0 Within a session, these streams can be tagged = with a
=C2=A0 =C2=A0number of identifiers, including CNAMEs and MSIDs
=C2=A0 =C2=A0[I-D.ietf-mmusic-msid].=C2=A0 Unfortunately, none of these hav= e the proper
=C2=A0 =C2=A0ordinality to refer to an individual stream; all such identifi= ers can
=C2=A0 =C2=A0appear in more than one stream at a time.=C2=A0 While approach= es that use
=C2=A0 =C2=A0unique Payload Types (PTs) per stream have been used in some =C2=A0 =C2=A0applications,

I think the usage of Stream should at least on the first usage say "RT= P Stream" and with a reference to RFC7656 to make it clear what entity= you are discussing in this paragraph.=C2=A0

3. Section 3:

=C2=A0 =C2=A0For Encoded Streams, the RID refers to the "Source RTP St= ream" as
=C2=A0 =C2=A0defined by [RFC7656] Section 2.1.10.=C2=A0 For Dependent Strea= ms, it
=C2=A0 =C2=A0refers to the RTP Stream that, like the Source RTP Stream of a= n
=C2=A0 =C2=A0Encoded Stream, is the RTP Stream that is not a Redundancy RTP=
=C2=A0 =C2=A0Stream.=C2=A0 For conciseness, we define the term "RID RT= P Stream" to
=C2=A0 =C2=A0refer to this construct.

I think this definition is not correct. From my perspective it might be bet= ter to talk about the RTP stream produced by the media packetizer from a en= coded or set of dependent streams. I write a set of dependent stream as on = RTP stream can be produced by packetizing multiple dependent streams in the= same. This would occur if one is not producing different RTP streams for a= ll produced scalability layers.

However, the main issue is that the definition does not correctly identifie= s what the RID refers to. To my understanding the RID refers to one RTP str= eam [A] packetized from either one encoded stream and zero or more dependen= t streams, or one or more dependent streams and the one or more redundancy = streams protecting the RTP stream [A].

The RID identifies an RTP strea= m that is not a Redundancy RTP Stream. =C2=A0
=E2=80=8BThat's all there is to it. =C2=A0

=E2=80=8BAn Encoded Stream has one non-Redundancy RTP Stream called= the Source RTP Stream.=C2=A0 A RID refers to that RTP Stream.
=

A Dependent Stream =E2=80=8B
=E2=80= =8B
=E2=80=8Bhas one non-Redundancy RTP Stream which, exac= tly like the Encoded Stream, but which doesn't have a name in the taxon= o=E2=80=8Bmy draft.=C2=A0 Call it the "Dependent Source RTP Stream&quo= t; if you like. =C2=A0 =C2=A0A RID refers to that RTP Stream.
<= br>



This also has the consequence that RID RTP Stream is not a suitable term as= the RID identifies an possible aggregate of RTP streams, one source and ze= ro or more redundancy RTP streams.

Since the RID only = identifies one RTP Stream, it cannot be an aggregate stream, since a
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;display:inline">=C2=A0Source RTP Stream cannot be an aggregate of RTP stre= ams. =C2=A0=E2=80=8B


=C2=A0
=

The above changed definition could be used, however I am not certain that i= t is what we really like to use here. For that purpose see next comment.
4. Section 3:

=C2=A0 =C2=A0For clarity, when RID is used, Redundancy RTP Streams that can= be
=C2=A0 =C2=A0used to repair Received RTP Streams will use the same RID valu= e as
=C2=A0 =C2=A0the Received RTP Stream they are intended to be combined with.= =C2=A0 If
=C2=A0 =C2=A0applications want to identify individual redundancy streams, t= hey can
=C2=A0 =C2=A0add an RRID to them instead of or in addition to the RID.

So the intention with RRID, is to identify Redundancy RTP streams. Consider= ing that RID doesn't actually only represent the source RTP stream for = the media, there is a mismatch.

The RID= *does* identify the Source RTP Stream (or the unnamed equivalent of =E2=80= =8Ba Dependent Stream).=C2=A0

The RID identifies= a non-Redudancy RTP Stream.
The RRID identifies a Redundancy RTP S= tream.


Also, the needs for RRID is also not clear, however, the basics of= identifying the RTP stream only has the advantage of high likelihood of re= -use in other mechanisms.

=E2=80=8BI don't see the need either, but Colin asked for it. =C2= =A0
=E2=80=8B
=C2=A0

However, I would like to take a collected consideration of the RID and RRID= definitions and actually propose that we change the RID definition. To be = clear on that this is another definition this new identifier I will refer t= o as RTP Stream IDentifier (SID).

The definition of SID would be: "An identifier for a single RTP stream= ."

=E2=80=8BThat's basicall= y what RRID is.=C2=A0 We even considered calling it SID, I believe.=C2=A0 F= or a non-Redundancy RTP Stream, an RRID =3D=3D RID, so it would just use RI= D and not RRID.
=C2=A0

This of course have implication on the RID mechanism expressing the payload= format constraints. However, I think it fulfil the basic needs very nicely= . The a=3Drid lines points at a SID for which is the RTP stream for which t= he set of constraints apply.

=E2=80= =8BIf an "a=3Drid' line points to a SID and not a RID, I think we&= #39;ve be just confusing ourselves way more than we need to.=C2=A0 But sinc= e RID=3D=3DSID for a non-Redundancy RTP Stream, it doesn't matter.


This is the basic part of the RID proposal. And this removes the need for R= RID, as also Redundancy RTP streams can have a SID, if needed by the applic= ation. We get a generic basic identification that is likely to be re-usable= while solving the current needs.
=E2=80=8BAt that point, you've basically just ren= amed RRID to SID. =C2=A0=E2=80=8B =C2=A0The real question, though, is what = goes in the header extension of the Redundancy RTP Stream.=C2=A0 The whole = point of RIDs in the first place is to allow the Redundancy RTP Stream to r= efer to the non-Redundancy RTP Stream.=C2=A0 Referring to itself is useless= .=C2=A0 So we still need a header extension that means "The ID of the = non-Redundancy RTP Stream".


We have= a few options for doing so:

Option A (current draft):=

non-Redundancy referring to self: RID
Redundancy Refererring to self: RRID
Redundancy Referring to = non-Redundancy: RID

Option B (your prop= osal):

non-Redundancy ref= erring to self: SID
Redundancy Refererrin= g to self: SID
Redundancy Referring to no= n-Redundancy: ???

Option C=E2=80=8B
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">
non-Redundancy referring to sel= f: SID or RID (either way!)
Redundancy Re= fererring to self: SID
Redundancy Referri= ng to non-Redundancy: RID

I'd be happy= with Option C, as long as the header extension allows the Redundancy RTP S= tream to include the RID and not the SID of itself. =C2=A0
=E2=80=8B =E2=80=8B
=C2=A0

Some may protest, hey but we are loosing the coupling method between the so= urce RTP stream and the Redundancy stream. Yes, I have a proposal below for= how to resolve that, but at the same time, it is this coupling that create= s the complicated definition of the RID SDES item. And this is actually qui= te a separate problem. One which has existed for some time, and may actuall= y benefit from being taken on a separate work item. Especially as we may wa= nt to retrofit the outcome onto some existing mechanisms such as RTP Retran= smission and Generic XOR FEC to enable single RTP session usage efficiently= for both.

So below is a possible solution if one desire to have a way of coupling the= redundancy stream to the source RTP stream already in signalling and ident= ifying it with the same properties as we get with RID for the Source RTP st= reams.

The solution is simple, we simply have a=3DRID lines also for the Redundanc= y RTP streams. Then we define a new constraint which I will call "prot= ect" which is a list of SIDs that points at one or more RTP streams fo= r which this Redundancy RTP Stream is constrained to protect and provide re= dundancy for.
=E2=80=8B
No, no, no.= =C2=A0 There is no need for requiring this to be signalled, or for this to = be in SDP.=C2=A0 That's just useless complexity. =C2=A0

I'm fine with renaming RRID to SID = and tweaking the definition, but I'm not OK with adding a bunch of SDP = complexity where we don't need it.

=
=C2=A0

An basic SDP example for this would be the following:

=C2=A0 =C2=A0m=3Dvideo 10000 RTP/SAVPF 100 101 108 109
=C2=A0 =C2=A0a=3Drtpmap:100 H264/90000
=C2=A0 =C2=A0a=3Dfmtp:100 profile-level-id=3D42401f; packetization-mode=3D0=
=C2=A0 =C2=A0a=3Drtpmap:101 H264/90000
=C2=A0 =C2=A0a=3Dfmtp:101 profile-level-id=3D42401f; packetization-mode=3D1=
=C2=A0 =C2=A0a=3Drtpmap:108 rtx/90000
=C2=A0 =C2=A0a=3Dfmtp:108 apt=3D100
=C2=A0 =C2=A0a=3Drtpmap:109 rtx/90000
=C2=A0 =C2=A0a=3Dfmtp:109 apt=3D101
=C2=A0 =C2=A0a=3Dsendrecv
=C2=A0 =C2=A0a=3Dmid:v1 (max resolution)
=C2=A0 =C2=A0a=3Drid:1 send max-width=3D1280;max-height=3D720;max-fps=3D30<= br> =C2=A0 =C2=A0a=3Drid:2 recv max-width=3D1280;max-height=3D720;max-fps=3D30<= br> =C2=A0 =C2=A0a=3Drid:A send pt=3D108,109;protect=3D1
=C2=A0 =C2=A0a=3Drid:B recv pt=3D108,109;protect=3D2

So at RTP session startup when the offerer of the above starts sending it w= ill send two RTP streams from the above block. One for the video using SID= =3D1 and another for the RTX packets using SID=3DA.


5. Section 4 and 6.

What I am missing in this is a discussion of privacy and the potential for = tracking the streams across an RTP system. This is usually fine, but may re= veal things to a third party, thus their value should be protected towards = third parties.

The next part of this issue is the generation of these values should avoid = leaking any information about the user and implementation. This leads to th= e question if the values should be using random values, with tag lengths as= needed by the application.


Cheers

Magnus Westerlund

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


--001a113557a0abc67e052fa983c6-- From nobody Mon Apr 4 15:10:58 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B7612D8DB for ; Mon, 4 Apr 2016 15:10:54 -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 YPF0pa5JWxZi for ; Mon, 4 Apr 2016 15:10:53 -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 CD60312D8DC for ; Mon, 4 Apr 2016 15:10:42 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-7b-5702e660a4f1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1A.A5.16394.066E2075; Tue, 5 Apr 2016 00:10:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Tue, 5 Apr 2016 00:10:38 +0200 To: Peter Thatcher References: <56FD3492.8080600@ericsson.com> <57012FC5.7040705@nostrum.com> <5702797D.1020600@ericsson.com> From: Magnus Westerlund Message-ID: <5702E658.2030507@ericsson.com> Date: Mon, 4 Apr 2016 19:10:32 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM2K7hG7iM6Zwg4XHmSz2/F3EbvHx3g1W i2vLX7M6MHss2FTqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlfN66jbGgS7ji4o6zrA2M +3i7GDk5JARMJDZt38QOYYtJXLi3ng3EFhI4wihxewFQDReQvYxR4sO3eWAJYQELib9zJoE1 iAhoSkye3MwKUfSMUWL9wv+sIAlmATeJpz+WMIPYbEANN380gjXzCmhLfNr5CKyGRUBFYufm k0wgtqhAjMTxd+cYIWoEJU7OfMICYnMKBEq0nfvMBjHTQmLm/POMELa8RPPW2cwQl2pLNDR1 sE5gFJyFpH0WkpZZSFoWMDKvYhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAgM4YNbfqvuYLz8 xvEQowAHoxIP74JTjOFCrIllxZW5hxglOJiVRHj3PWQKF+JNSaysSi3Kjy8qzUktPsQozcGi JM6bHfkvTEggPbEkNTs1tSC1CCbLxMEp1cBonrx6+oo+uVUGupUmt2duyf987WL45eOWtR+z DUPyoic1myoV9L/4d2PDyQ1pfbfUHvwLedFvcs/bgUth+iTRg1PUJhjOsO/+e9Qq+4aU8NF9 59bu5pnJ8sfhXdidWUbbl25QPlNcGcHAflV9s4JdsoX8ruqvC+6L3X5zPXlW3GPe11YLpQ6f UmIpzkg01GIuKk4EAD0YiRldAgAA Archived-At: Cc: "avtext@ietf.org" Subject: Re: [avtext] WGLC: draft-ietf-avtext-rid-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 22:10:54 -0000 Den 2016-04-04 kl. 11:29, skrev Peter Thatcher: > > On Mon, Apr 4, 2016 at 7:26 AM, Magnus Westerlund > > > wrote: > > Hi, > > 4. Section 3: > > For clarity, when RID is used, Redundancy RTP Streams > that can be > used to repair Received RTP Streams will use the same > RID value as > the Received RTP Stream they are intended to be combined > with. If > applications want to identify individual redundancy > streams, they can > add an RRID to them instead of or in addition to the RID. > > So the intention with RRID, is to identify Redundancy RTP > streams. > Considering that RID doesn't actually only represent the > source RTP > stream for the media, there is a mismatch. > > > I'm confused. If I read the text you quoted above, it's pretty > clear: > "For Encoded Streams, the RID refers to the 'Source RTP Stream'". It > then builds a parallel construct for dependent streams, but > these are > always going to have a different RID than their corresponding > encoded > streams. > > > So my understanding is that the RID actually represent the aggregate > of the RTP source stream and the redundancy, from that perspective, > term RTP stream Identifier is the wrong term. > > > ​No, it does not represent the aggregate. It represents one RTP Stream. ​ > Okay, then it is wrong to put the SID on the RTP Redundancy stream using the RTP header extension for RID. Then that should have another header extension or rely on the signalling layer to create the relation and explicitly Identify the redundancy stream also using the SID. 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 Apr 6 11:34:29 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D9612D158; Wed, 6 Apr 2016 11:34:26 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160406183426.24947.91140.idtracker@ietfa.amsl.com> Date: Wed, 06 Apr 2016 11:34:26 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:34:26 -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-06.txt Pages : 19 Date : 2016-04-06 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 6 11:39:05 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 91C3A12D741 for ; Wed, 6 Apr 2016 11:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQ7pUn1bU7RD for ; Wed, 6 Apr 2016 11:39:02 -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 12FF612D668 for ; Wed, 6 Apr 2016 11:38:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGY70843; Wed, 06 Apr 2016 18:38:53 +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, 6 Apr 2016 19:38:52 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 02:38:48 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext]Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt Thread-Index: AQHRkDOORi5WTyzrvkCwDnMW1enWKQ== Date: Wed, 6 Apr 2016 18:38:48 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.188] 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.570557BD.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c383fd8de36196d87874f1781784a02f Archived-At: Subject: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 18:39:04 -0000 SGksDQoNClRoaXMgbmV3IHZlcnNpb24gYWRkcmVzc2VzIE1hZ251cydzIGNvbW1lbnQgb2YgdXNp bmcgYW4gYWdub3N0aWMgZm9ybWF0LiBUaGF0J3MgdGhlIG9ubHkgY2hhbmdlIG1hZGUgaW4gdGhp cyB2ZXJzaW9uLg0KDQpCUiwNClJhY2hlbA0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hk u7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTblubQ05pyIN+aXpSAyOjM0DQrmlLbku7bkuro6 IERlbmcgTGluZ2xpOyBSb25pIEV2ZW47IFhpYWppbndlaTsgSHVhbmd5aWhvbmcgKFJhY2hlbCk7 IExpbmdsaSBEZW5nDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA2LnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDYudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFJhY2hlbCBIdWFuZyBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLWF2dGV4dC1z cGxpY2luZy1ub3RpZmljYXRpb24NClJldmlzaW9uOgkwNg0KVGl0bGU6CQlSVFAvUlRDUCBleHRl bnNpb24gZm9yIFJUUCBTcGxpY2luZyBOb3RpZmljYXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTYt MDQtMDYNCkdyb3VwOgkJYXZ0ZXh0DQpQYWdlczoJCTE5DQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5n LW5vdGlmaWNhdGlvbi0wNi50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24vDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0 ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmlj YXRpb24tMDYNCg0KQWJzdHJhY3Q6DQogICBDb250ZW50IHNwbGljaW5nIGlzIGEgcHJvY2VzcyB0 aGF0IHJlcGxhY2VzIHRoZSBjb250ZW50IG9mIGEgbWFpbg0KICAgbXVsdGltZWRpYSBzdHJlYW0g d2l0aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQsIGFuZCBkZWxpdmVycyB0aGUNCiAgIHN1YnN0 aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgdG8gdGhlIHJlY2VpdmVycyBmb3IgYSBwZXJpb2Qg b2YNCiAgIHRpbWUuIFRoZSBzcGxpY2VyIGlzIGRlc2lnbmVkIHRvIGhhbmRsZSBSVFAgc3BsaWNp bmcgYW5kIG5lZWRzIHRvDQogICBrbm93IHdoZW4gdG8gc3RhcnQgYW5kIGVuZCB0aGUgc3BsaWNp bmcuDQoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIHR3byBSVFAvUlRDUCBleHRlbnNpb25zIHRvIGlu ZGljYXRlIHRoZSBzcGxpY2luZw0KICAgcmVsYXRlZCBpbmZvcm1hdGlvbiB0byB0aGUgc3BsaWNl cjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdA0KICAgY29udmV5cyB0aGUgaW5mb3JtYXRp b24gaW4tYmFuZCBhbmQgYW4gUlRDUCBwYWNrZXQgdGhhdCBjb252ZXlzIHRoZQ0KICAgaW5mb3Jt YXRpb24gb3V0LW9mLWJhbmQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBh dmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Fri Apr 8 07:06:15 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AA912D8E8 for ; Fri, 8 Apr 2016 07:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2VkpUhFXRq9 for ; Fri, 8 Apr 2016 07:06:07 -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 02FA312D8EF for ; Fri, 8 Apr 2016 07:06:06 -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 CHB30826; Fri, 08 Apr 2016 14:06:04 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 8 Apr 2016 15:06:04 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Fri, 8 Apr 2016 22:06:00 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] avtext minutes for IETF95 Thread-Index: AdGRn8500i4Sb04zT/+oABSiC4XD2A== Date: Fri, 8 Apr 2016 14:05:59 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86E9F578@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.196.9] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9F578nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.5707BACD.002C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98b8295ddd87ce8ea4cefc7cb7418588 Archived-At: Subject: [avtext] avtext minutes for IETF95 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:06:14 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9F578nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Minutes for yesterday's session is available now. Thanks to Roni for scribi= ng it. https://www.ietf.org/proceedings/95/minutes/minutes-95-avtext Please reply with any corrections, fixes, or patches. Thanks! Jonathan and Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9F578nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Minutes for yesterday’s s= ession is available now. Thanks to Roni for scribing it.

 

https://www.ietf.org/proceeding= s/95/minutes/minutes-95-avtext

 

Please reply with any correctio= ns, fixes, or patches. Thanks!

 

Jonathan and Rachel<= /span>

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86E9F578nkgeml513mbxchi_-- From nobody Fri Apr 8 14:17: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 938B312D140 for ; Fri, 8 Apr 2016 14:17:07 -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 KgaIiC8rnPJP for ; Fri, 8 Apr 2016 14:17:05 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61C2112D129 for ; Fri, 8 Apr 2016 14:17:05 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-66-57081fcf479c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.42.30858.FCF18075; Fri, 8 Apr 2016 23:17:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.248.2; Fri, 8 Apr 2016 23:16:12 +0200 To: "Huangyihong (Rachel)" , "avtext@ietf.org" References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: <57081F97.2030009@ericsson.com> Date: Fri, 8 Apr 2016 18:16:07 -0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7iu55eY5wg5Y9KhYf791gtVjaeYrd gcmj5chbVo8lS34yBTBFcdmkpOZklqUW6dslcGVs2BxV0ChTcfzdQsYGxuViXYycHBICJhJ/ Z9xih7DFJC7cW8/WxcjFISRwhFHi95L37BDOMkaJSXPfMXYxcnAIC2RIbDnBAtIgIhAtcfZh F5gtJBAqMf1pHzOIzSZgIXHzRyMbiM0roC2x8Hg3E4jNIqAicfDOT0YQW1QgRuL4u3OMEDWC EidnPgGbwykQJrF1SguYzQw0Z+b884wQtrxE89bZzBC7tCUamjpYJzAKzELSPgtJyywkLQsY mVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBAblwS2/DXYwvnzueIhRgINRiYd3gQB7uBBr YllxZe4hRgkOZiUR3vWiHOFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEebMj/4UJCaQnlqRmp6YW pBbBZJk4OKUaGGd7SnYv+CRiFXnv4bmdvbZPGAqyd8psDbtk1bLvpueblKu1khsUtr/weBfj qrEzb+vjl+0euYp11q+OWlQLVG+u5dtxyWTunYXiatMWFFR2x2rO4Vm739Pmx0eDmbZcX29/ NdcVvHxtmnjMhqSO+ce79n59tsVvVcCZ3dUb5jyUWD8pqEsv/qYSS3FGoqEWc1FxIgCZg2v3 RgIAAA== Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 21:17:07 -0000 Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): > Hi, > > This new version addresses Magnus's comment of using an agnostic > format. That's the only change made in this version. Hi, So I have reviewed all the changes from the -04 to this -06 version. First, I think people should be aware that the latest change do change the data format of the splicing header extension. This was not my intention, but I also don't care about. Just that people should be aware of this. I understand this is to enable the 2-bytes format to align with the 32-byte boundaries when it is the sole header extension present. However, I would note that this is a unnecessary alignment most likely. This header extension, even when using 7-byte splicing out timestamps do fit within the 1-byte header extension. Thus, in most cases the sole reason for using the 2-byte header extension would be in cases where this header extension is included together with another header extension requiring the 2-byte header extension header. So from my perspective, the old 7-byte header extension could be used with both the 1 and 2-byte headers. My other comment is that the Security consideration section still has issues from my perspective: Since splicer works as a trusted entity, any RTP-level or outside security mechanism, such IPsec[RFC4301] or Datagram Transport Layer Security [RFC6347], will use a security association between the splicer and the receiver. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned with the same security association as the main RTP sender. So the alternatives when SRTP is to protect the content from the Splicer to the Receiver, then the splicer either has its own security context on the splicer to receiver leg, or it has as indicated access to the security context from main RTP sender. Then the following paragraph seem to lack a requirement for authenticating the actual splicing notification, i.e. the whole RTP packet that it is included in. The text appear to discuss both the substitute RTP stream and if the notification is modified, but not an authentication requirement to avoid this. For cases that the splicing time information is changed by a malicious endpoint, the splicing may fail since it will not be available at the right time for the substitutive media to arrive That is not the only issue, it can also be used to hide content that the main RTP sender intended to recieve. I think here is the right place to insert the authentication need. , which 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. The undetectable part is a separate issue, please write it as separate sentences. Thanks for addressing the other issues. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 11 19:43:42 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 33F7812DE4B for ; Mon, 11 Apr 2016 19:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 bTiDlEGbbuzc for ; Mon, 11 Apr 2016 19:43:39 -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 A39DD12DE36 for ; Mon, 11 Apr 2016 19:43:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHE35210; Tue, 12 Apr 2016 02:43:36 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 03:43:35 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 10:43:23 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: call for adoption of draft-wenger-avtext-avpf-ccm-layered Thread-Index: AdGUZRQu3nbG30cwRZCPB3sk/HqHtg== Date: Tue, 12 Apr 2016 02:43:22 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EA0418@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.75] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA0418nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.570C60D9.0004, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3d4e8cb82764d8d20c5e146e5ebf4308 Archived-At: Subject: [avtext] call for adoption of draft-wenger-avtext-avpf-ccm-layered X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 02:43:41 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA0418nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, This draft has been discussed in the Buenos Aires meeting, and there was co= nsensus to adopt it as a work item, but subject to the confirmation on the = list. So let's get it done: Please respond to indicate if you support the adoption of https://tools.iet= f.org/html/ draft-wenger-avtext-avpf-ccm-layered as a working group work it= em. And please respond it before April 22th, 2016. Thanks. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA0418nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

This draft has been discussed i= n the Buenos Aires meeting, and there was consensus to adopt it as a work i= tem, but subject to the confirmation on the list. So let’s get it don= e:

 

Please respond to indicate if y= ou support the adoption of https://tools.ietf.org/html/ draft-wenger-avtext= -avpf-ccm-layered as a working group work item. And please respond it befor= e April 22th, 2016. Thanks.

 

BR,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA0418nkgeml513mbxchi_-- From nobody Tue Apr 12 02:36:23 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 3F7AD12D605 for ; Tue, 12 Apr 2016 02:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.217 X-Spam-Level: X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 ufto7FsDw7eB for ; Tue, 12 Apr 2016 02:36:19 -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 C0E1212E029 for ; Tue, 12 Apr 2016 02:36:18 -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 CLX89087; Tue, 12 Apr 2016 09:36:15 +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, 12 Apr 2016 10:36:14 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 17:36:06 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt Thread-Index: AQHRkdyyduEzFzil3kGXbQ2A5yKoH5+GB/KQ Date: Tue, 12 Apr 2016 09:36:06 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EA05A3@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> In-Reply-To: <57081F97.2030009@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.78.75] 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.570CC190.008B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8fae549a29346cf7fd049721b6e8a7a1 Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 09:36:21 -0000 SGkgTWFnbnVzLA0KDQpJbmxpbmUgcGxlYXNlLg0KDQpCUiwNClJhY2hlbA0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzpt YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAw OSwgMjAxNiA1OjE2IEFNDQo+IFRvOiBIdWFuZ3lpaG9uZyAoUmFjaGVsKTsgYXZ0ZXh0QGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbYXZ0ZXh0XSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTA2LnR4dA0K PiANCj4gRGVuIDIwMTYtMDQtMDYga2wuIDE1OjM4LCBza3JldiBIdWFuZ3lpaG9uZyAoUmFjaGVs KToNCj4gPiBIaSwNCj4gPg0KPiA+IFRoaXMgbmV3IHZlcnNpb24gYWRkcmVzc2VzIE1hZ251cydz IGNvbW1lbnQgb2YgdXNpbmcgYW4gYWdub3N0aWMNCj4gPiBmb3JtYXQuIFRoYXQncyB0aGUgb25s eSBjaGFuZ2UgbWFkZSBpbiB0aGlzIHZlcnNpb24uDQo+IA0KPiBIaSwNCj4gDQo+IFNvIEkgaGF2 ZSByZXZpZXdlZCBhbGwgdGhlIGNoYW5nZXMgZnJvbSB0aGUgLTA0IHRvIHRoaXMgLTA2IHZlcnNp b24uDQo+IA0KPiBGaXJzdCwgSSB0aGluayBwZW9wbGUgc2hvdWxkIGJlIGF3YXJlIHRoYXQgdGhl IGxhdGVzdCBjaGFuZ2UgZG8gY2hhbmdlIHRoZSBkYXRhDQo+IGZvcm1hdCBvZiB0aGUgc3BsaWNp bmcgaGVhZGVyIGV4dGVuc2lvbi4gVGhpcyB3YXMgbm90IG15IGludGVudGlvbiwgYnV0IEkgYWxz bw0KPiBkb24ndCBjYXJlIGFib3V0LiBKdXN0IHRoYXQgcGVvcGxlIHNob3VsZCBiZSBhd2FyZSBv ZiB0aGlzLiBJIHVuZGVyc3RhbmQgdGhpcyBpcw0KPiB0byBlbmFibGUgdGhlIDItYnl0ZXMgZm9y bWF0IHRvIGFsaWduIHdpdGggdGhlIDMyLWJ5dGUgYm91bmRhcmllcyB3aGVuIGl0IGlzIHRoZQ0K PiBzb2xlIGhlYWRlciBleHRlbnNpb24gcHJlc2VudC4NCj4gSG93ZXZlciwgSSB3b3VsZCBub3Rl IHRoYXQgdGhpcyBpcyBhIHVubmVjZXNzYXJ5IGFsaWdubWVudCBtb3N0IGxpa2VseS4NCj4gVGhp cyBoZWFkZXIgZXh0ZW5zaW9uLCBldmVuIHdoZW4gdXNpbmcgNy1ieXRlIHNwbGljaW5nIG91dCB0 aW1lc3RhbXBzIGRvIGZpdA0KPiB3aXRoaW4gdGhlIDEtYnl0ZSBoZWFkZXIgZXh0ZW5zaW9uLiBU aHVzLCBpbiBtb3N0IGNhc2VzIHRoZSBzb2xlIHJlYXNvbiBmb3INCj4gdXNpbmcgdGhlIDItYnl0 ZSBoZWFkZXIgZXh0ZW5zaW9uIHdvdWxkIGJlIGluIGNhc2VzIHdoZXJlIHRoaXMgaGVhZGVyDQo+ IGV4dGVuc2lvbiBpcyBpbmNsdWRlZCB0b2dldGhlciB3aXRoIGFub3RoZXIgaGVhZGVyIGV4dGVu c2lvbiByZXF1aXJpbmcgdGhlDQo+IDItYnl0ZSBoZWFkZXIgZXh0ZW5zaW9uIGhlYWRlci4gU28g ZnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIG9sZCA3LWJ5dGUgaGVhZGVyDQo+IGV4dGVuc2lvbiBj b3VsZCBiZSB1c2VkIHdpdGggYm90aCB0aGUgMSBhbmQgMi1ieXRlIGhlYWRlcnMuDQoNCltSYWNo ZWxdOiBZZXMsIEkgYWdyZWUuIEJvdGggNy1ieXRlIGFuZCA2LWJ5dGUgZXh0ZW5zaW9uIGFyZSBh cHBsaWNhYmxlIGluIHRoaXMgY2FzZS4gVGhlIG9ubHkgZGlmZmVyZW5jZSBpcyBhbGlnbm1lbnQg YW5kIGJpdCBzYXZpbmcuIFNvIGlmIHlvdSB0aGluayB0aGF0IHRoZXJlJ3Mgbm8gbmVlZCB0byBo YXZlIHN1Y2ggY29uc2lkZXJhdGlvbiwgSSdsbCBjaGFuZ2UgaXQgdG8gb2xkIDctYnl0ZS4NCg0K PiANCj4gTXkgb3RoZXIgY29tbWVudCBpcyB0aGF0IHRoZSBTZWN1cml0eSBjb25zaWRlcmF0aW9u IHNlY3Rpb24gc3RpbGwgaGFzIGlzc3Vlcw0KPiBmcm9tIG15IHBlcnNwZWN0aXZlOg0KPiANCj4g ICAgIFNpbmNlIHNwbGljZXIgd29ya3MgYXMgYSB0cnVzdGVkIGVudGl0eSwgYW55IFJUUC1sZXZl bCBvciBvdXRzaWRlDQo+ICAgICBzZWN1cml0eSBtZWNoYW5pc20sIHN1Y2ggSVBzZWNbUkZDNDMw MV0gb3IgRGF0YWdyYW0gVHJhbnNwb3J0IExheWVyDQo+ICAgICBTZWN1cml0eSBbUkZDNjM0N10s IHdpbGwgdXNlIGEgc2VjdXJpdHkgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGUNCj4gICAgIHNwbGlj ZXIgYW5kIHRoZSByZWNlaXZlci4gV2hlbiB1c2luZyB0aGUgU2VjdXJlIFJlYWwtVGltZSBUcmFu c3BvcnQNCj4gICAgIFByb3RvY29sIChTUlRQKSBbUkZDMzcxMV0sIHRoZSBzcGxpY2VyIGNvdWxk IGJlIHByb3Zpc2lvbmVkIHdpdGggdGhlDQo+ICAgICBzYW1lIHNlY3VyaXR5IGFzc29jaWF0aW9u IGFzIHRoZSBtYWluIFJUUCBzZW5kZXIuDQo+IA0KPiBTbyB0aGUgYWx0ZXJuYXRpdmVzIHdoZW4g U1JUUCBpcyB0byBwcm90ZWN0IHRoZSBjb250ZW50IGZyb20gdGhlIFNwbGljZXIgdG8gdGhlDQo+ IFJlY2VpdmVyLCB0aGVuIHRoZSBzcGxpY2VyIGVpdGhlciBoYXMgaXRzIG93biBzZWN1cml0eSBj b250ZXh0IG9uIHRoZSBzcGxpY2VyIHRvDQo+IHJlY2VpdmVyIGxlZywgb3IgaXQgaGFzIGFzIGlu ZGljYXRlZCBhY2Nlc3MgdG8gdGhlIHNlY3VyaXR5IGNvbnRleHQgZnJvbSBtYWluIFJUUA0KPiBz ZW5kZXIuDQo+IA0KPiBUaGVuIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIHNlZW0gdG8gbGFjayBh IHJlcXVpcmVtZW50IGZvciBhdXRoZW50aWNhdGluZw0KPiB0aGUgYWN0dWFsIHNwbGljaW5nIG5v dGlmaWNhdGlvbiwgaS5lLiB0aGUgd2hvbGUgUlRQIHBhY2tldCB0aGF0IGl0IGlzIGluY2x1ZGVk IGluLg0KPiBUaGUgdGV4dCBhcHBlYXIgdG8gZGlzY3VzcyBib3RoIHRoZSBzdWJzdGl0dXRlIFJU UCBzdHJlYW0gYW5kIGlmIHRoZQ0KPiBub3RpZmljYXRpb24gaXMgbW9kaWZpZWQsIGJ1dCBub3Qg YW4gYXV0aGVudGljYXRpb24gcmVxdWlyZW1lbnQgdG8gYXZvaWQgdGhpcy4NCj4gDQo+ICAgICBG b3IgY2FzZXMgdGhhdCB0aGUgc3BsaWNpbmcgdGltZSBpbmZvcm1hdGlvbiBpcyBjaGFuZ2VkIGJ5 IGENCj4gICAgIG1hbGljaW91cyBlbmRwb2ludCwgdGhlIHNwbGljaW5nIG1heSBmYWlsIHNpbmNl IGl0IHdpbGwgbm90IGJlDQo+ICAgICBhdmFpbGFibGUgYXQgdGhlIHJpZ2h0IHRpbWUgZm9yIHRo ZSBzdWJzdGl0dXRpdmUgbWVkaWEgdG8gYXJyaXZlDQo+IA0KPiBUaGF0IGlzIG5vdCB0aGUgb25s eSBpc3N1ZSwgaXQgY2FuIGFsc28gYmUgdXNlZCB0byBoaWRlIGNvbnRlbnQgdGhhdCB0aGUgbWFp biBSVFANCj4gc2VuZGVyIGludGVuZGVkIHRvIHJlY2lldmUuIEkgdGhpbmsgaGVyZSBpcyB0aGUg cmlnaHQgcGxhY2UgdG8gaW5zZXJ0IHRoZQ0KDQpbUmFjaGVsXTogV2hhdCBkbyB5b3UgbWVhbiBi eSBoaWRpbmcgY29udGVudCB0aGF0IHRoZSBtYWluIFJUUCBzZW5kZXIgaW50ZW5kZWQgdG8gcmVj ZWl2ZT8gSSBjYW4gc2VlIHRoYXQgaXQgb25seSBoaWRlcyB0aGUgY29udGVudCB0aGF0IHRoZSBz dWJzdGl0dXRpdmUgc2VuZGVyIHdhbnRzIHRvIHNlbmQgdG8gdGhlIHJlY2VpdmVycywgYnV0IHRo ZSBtYWluIFJUUCBzZW5kZXIuLi4/IFdoYXQgZG8gSSBtaXNzPw0KDQo+IGF1dGhlbnRpY2F0aW9u IG5lZWQuDQoNCltSYWNoZWxdOiBTbyBob3cgYWJvdXQgdGhlIGZvbGxvd2luZyBjaGFuZ2VzPw0K DQpPTEQNCiINCiAgIEZvciBjYXNlcyB0aGF0IHRoZSBzcGxpY2luZyB0aW1lIGluZm9ybWF0aW9u IGlzIGNoYW5nZWQgYnkgYQ0KICAgbWFsaWNpb3VzIGVuZHBvaW50LCB0aGUgc3BsaWNpbmcgbWF5 IGZhaWwgc2luY2UgaXQgd2lsbCBub3QgYmUNCiAgIGF2YWlsYWJsZSBhdCB0aGUgcmlnaHQgdGlt ZSBmb3IgdGhlIHN1YnN0aXR1dGl2ZSBtZWRpYSB0byBhcnJpdmUsDQogICB3aGljaCBtYXkgYWxz byBicmVhayBhbiB1bmRldGVjdGFibGUgc3BsaWNpbmcuIFRvIG1pdGlnYXRlIHRoaXMNCiAgIGVm ZmVjdCwgdGhlIHNwbGljZXIgU0hPVUxEIE5PVCBmb3J3YXJkIHRoZSBzcGxpY2luZyB0aW1lIGlu Zm9ybWF0aW9uDQogICBSVFAgaGVhZGVyIGV4dGVuc2lvbiBkZWZpbmVkIGluIFNlY3Rpb24gNC4x IHRvIHRoZSByZWNlaXZlcnMuIEFuZCBpdA0KICAgTVVTVCBOT1QgZm9yd2FyZCB0aGlzIGhlYWRl ciBleHRlbnNpb24gd2hlbiBjb25zaWRlcmluZyBhbg0KICAgdW5kZXRlY3RhYmxlIHNwbGljaW5n Lg0KIg0KDQpORVcNCiINCiAgIEZvciBjYXNlcyB0aGF0IHRoZSBzcGxpY2luZyB0aW1lIGluZm9y bWF0aW9uIGlzIGNoYW5nZWQgYnkgYQ0KICAgbWFsaWNpb3VzIGVuZHBvaW50LCB0aGUgc3BsaWNp bmcgbWF5IGZhaWwgc2luY2UgaXQgd2lsbCBub3QgYmUNCiAgIGF2YWlsYWJsZSBhdCB0aGUgcmln aHQgdGltZSBmb3IgdGhlIHN1YnN0aXR1dGl2ZSBtZWRpYSB0byBhcnJpdmUuIFRvIGF2b2lkIGl0 LA0KIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBSVFAgaGVhZGVyIGV4dGVuc2lvbiBmb3Igc3BsaWNp bmcgdGltZSBpbmZvcm1hdGlvbiBTSE9VTEQgYmUgY29uc2lkZXJlZC4NCiINCg0KPiANCj4gLA0K PiAgICAgd2hpY2ggbWF5IGFsc28gYnJlYWsgYW4gdW5kZXRlY3RhYmxlIHNwbGljaW5nLiBUbyBt aXRpZ2F0ZSB0aGlzDQo+ICAgICBlZmZlY3QsIHRoZSBzcGxpY2VyIFNIT1VMRCBOT1QgZm9yd2Fy ZCB0aGUgc3BsaWNpbmcgdGltZSBpbmZvcm1hdGlvbg0KPiAgICAgUlRQIGhlYWRlciBleHRlbnNp b24gZGVmaW5lZCBpbiBTZWN0aW9uIDQuMSB0byB0aGUgcmVjZWl2ZXJzLiBBbmQgaXQNCj4gICAg IE1VU1QgTk9UIGZvcndhcmQgdGhpcyBoZWFkZXIgZXh0ZW5zaW9uIHdoZW4gY29uc2lkZXJpbmcg YW4NCj4gICAgIHVuZGV0ZWN0YWJsZSBzcGxpY2luZy4NCj4gDQo+IFRoZSB1bmRldGVjdGFibGUg cGFydCBpcyBhIHNlcGFyYXRlIGlzc3VlLCBwbGVhc2Ugd3JpdGUgaXQgYXMgc2VwYXJhdGUNCj4g c2VudGVuY2VzLg0KDQpbUmFjaGVsXTogT2theSwgdGhlbiBhIG5ldyBwYXJhZ3JhcGggY2FuIGJl IGFkZGVkIGluIHRoZSBlbmQuIEhvdyBhYm91dCB0aGF0Pw0KDQoiDQogICBXaGVuIHNwbGljaW5n IGZhaWxzLCB0aGUgc3BsaWNlciBTSE9VTEQgTk9UIGZvcndhcmQgdGhlIHNwbGljaW5nIHRpbWUg aW5mb3JtYXRpb24NCiAgIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGRlZmluZWQgaW4gU2VjdGlvbiA0 LjEgdG8gdGhlIHJlY2VpdmVycy4gQW5kIGl0DQogICBNVVNUIE5PVCBmb3J3YXJkIHRoZSBoZWFk ZXIgZXh0ZW5zaW9uIHdoZW4gY29uc2lkZXJpbmcgYW4NCiAgIHVuZGV0ZWN0YWJsZSBzcGxpY2lu Zy4NCiINCg0KPiANCj4gDQo+IFRoYW5rcyBmb3IgYWRkcmVzc2luZyB0aGUgb3RoZXIgaXNzdWVz Lg0KPiANCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4gDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZlYXR1cmVzLCBFcmljc3Nv biBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJpY3Nzb24gQUIgICAgICAg ICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLDtmdhdGFuIDYgICAgICAg ICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2NCA4MCBTdG9ja2hvbG0s IFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0K From nobody Mon Apr 18 02:33:31 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E0112DAB8; Mon, 18 Apr 2016 02:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 fCNDakvgwtYt; Mon, 18 Apr 2016 02:33:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A8312DAAB; Mon, 18 Apr 2016 02:33:26 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-f6-5714a9e54df3 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.8D.16963.5E9A4175; Mon, 18 Apr 2016 11:33:25 +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.248.2; Mon, 18 Apr 2016 11:33:12 +0200 To: Samuel Weiler , , , , "avtext@ietf.org" References: From: Magnus Westerlund Message-ID: <5714A9D6.4010602@ericsson.com> Date: Mon, 18 Apr 2016 11:33:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUyM2K7t+7TlSLhBlM7xCw+3rvBajFjygFm ixl/JjJbfFj4kMViwuvpTA6sHkuW/GTyWNqwmz2AKYrLJiU1J7MstUjfLoErY+6u7ywF29Qq DiyezNrAeF+ui5GTQ0LAROLmi6MsELaYxIV769m6GLk4hASOMErMu/GIHcJZziixbP0SdpAq YQEbibP3roIlRASWMUpMWf8ALCEk4CxxYPsOsFFsAhYSN380soHYvALaEq2z2lhBbBYBVYnr r16C1YsKxEg0PjjFBFEjKHFy5hOwXk4BF4nJD04A1XNwMAvYSzzYWgYSZhaQl2jeOpsZYpW2 RENTB+sERoFZSLpnIXTMQtKxgJF5FaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZg0B7c8ttq B+PB546HGAU4GJV4eBPYRcKFWBPLiitzDzFKcDArifC6rwAK8aYkVlalFuXHF5XmpBYfYpTm YFES582J/BcmJJCeWJKanZpakFoEk2Xi4JRqYHRZ31D2NfhIeZTZrK8cS/qmfJ88YUVpuExg 9+m23tM3RKZs7Pzr+PxgVORKvlPbtd6e5L7Sei/05qyJodO2eO6tqqkJLxXW4P/Q+2+i0/Kd 61SS9DI7lRQ7VJ0k6o1MzR+f2y0Q8N3044wMqUuHE8z1e2YzX7uupxPMfcJU9DCb/PwUwbKj t5RYijMSDbWYi4oTAQeWrVBWAgAA Archived-At: Subject: Re: [avtext] secdir review of draft-ietf-avtext-sdes-hdr-ext 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, 18 Apr 2016 09:33:29 -0000 Hi Samuel, (CC the WG) Thanks for the review. Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > > I am mostly satisfied with this document's security analysis. I am > worried that implementors will weasel their way around the "SHOULD"s, > but the appropriate "SHOULD"s are in the doc. > > The doc says "...there SHOULD be strong integrity protection and source > authentication of the header extensions" -- I would like to also see > specific citation(s). (e.g. "Use X for integrity protection." "Use X > for authenticity.") So I will claim that the common problem that exists with minor RTP extension and RTP payload formats (see RFC 7202) do apply here, we should at least reference RFC 7201 for the options in the security consideration section. I will edit our source and likely push out such a change quite soon so that it is in place in good time before the IESG call. Unless our AD objects. I propose to add the below to end of the last paragraph. "For information regarding options for securing RTP, see [RFC7201]." And add RFC7201 as an informative reference. > > It would be nice to see some discussion of whether these headers > increase the utility of RTP as a DOS vector - either by enabling a > reflector attack or by triggering heavy computation on a receiving > host. I suspect that there's not much to see here, particularly if > there really is integrity protection, but it would be nice to see the > analysis. Yes, this is a reasonable thing to consider. I suggest that we add the below paragraph before the last paragraph in the Security Consideration. The general RTP header extension mechanism does not itself contain any functionality that is a significant risk for a denial of service attack, nor from processing or storage requirements. This specific extension for SDES items, could potentially be a risk. If the received SDES item and its content causes the receiver to perform larger amount of processing, create significant storage structures, or emit more network traffic such a risk do exist. The CNAME SDES item is only a minor risk as reception of a CNAME item will create an association between the stream carrying the SDES item and other RTP streams with the same SDES item. As this can result in time synchronizing the media streams some additional processing may result. However, the applications media quality appear will be likely more affected of the wrongly or changing association, than from the impact caused by the additional processing. > > > Editorial comment: > > For the RTP-naive reader, I suggest adding an early mention that SDES > is (normally) a special packet type within RTP. Specifically: it > would be helpful for Section 1 to also say "RTP has a special packet > type for Source Description (SDES) items." I guess what you are intersted is an expansion of the following text: OLD: This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP source description (SDES) items. By including selected SDES items in a header extension the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES Item delivery. NEW (Second sentence): 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. By including selected SDES items in a header extension the determination of relationship and synchronization context for new RTP streams (SSRCs) in an RTP session can be optimized. Which relationship and what information depends on the SDES items carried. This becomes a complement to using only RTCP for SDES Item delivery. Does this addresses the editorial issue? Any feedback on the proposed changes? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Apr 18 02:49:03 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 7E96D12D8B9; Mon, 18 Apr 2016 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 p-8OZbx-48CU; Mon, 18 Apr 2016 02:48:58 -0700 (PDT) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by ietfa.amsl.com (Postfix) with ESMTP id C050E12D803; Mon, 18 Apr 2016 02:48:58 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [198.74.231.63]) by cyrus.watson.org (Postfix) with ESMTPS id E102946B35; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) Received: from fledge.watson.org (weiler@localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.15.2/8.15.2) with ESMTP id u3I9mvmG010755; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) (envelope-from weiler+ietf@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.15.2/8.15.2/Submit) with ESMTP id u3I9mvIi010751; Mon, 18 Apr 2016 05:48:57 -0400 (EDT) (envelope-from weiler+ietf@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 18 Apr 2016 05:48:56 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: Magnus Westerlund In-Reply-To: <5714A9D6.4010602@ericsson.com> Message-ID: References: <5714A9D6.4010602@ericsson.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (fledge.watson.org [127.0.0.1]); Mon, 18 Apr 2016 05:48:57 -0400 (EDT) Archived-At: Cc: draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , iesg@ietf.org, secdir@ietf.org Subject: Re: [avtext] [secdir] secdir review of draft-ietf-avtext-sdes-hdr-ext 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, 18 Apr 2016 09:49:01 -0000 On Mon, 18 Apr 2016, Magnus Westerlund wrote: > And add RFC7201 as an informative reference. That makes sense to me. > Yes, this is a reasonable thing to consider. I suggest that we add the below > paragraph before the last paragraph in the Security Consideration. .... This is the right idea. It would be good for someone else in the WG to weigh in on its correctness and completeness. The proposed text needs minor editting, but that can wait for the RFC Editor, if needed. > Does this addresses the editorial issue? Yes, perfectly. Thank you for the quick and receptive response. -- Sam From nobody Mon Apr 18 07:29:54 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 76F8E12D818; Mon, 18 Apr 2016 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 Ly11Cm6g0bVG; Mon, 18 Apr 2016 07:29: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 8EA9212D68D; Mon, 18 Apr 2016 07:29:44 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u3IETdTr008772 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 18 Apr 2016 09:29:39 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Magnus Westerlund" Date: Mon, 18 Apr 2016 09:29:38 -0500 Message-ID: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> In-Reply-To: <5714A9D6.4010602@ericsson.com> References: <5714A9D6.4010602@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , Samuel Weiler , secdir@ietf.org Subject: Re: [avtext] secdir review of draft-ietf-avtext-sdes-hdr-ext 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, 18 Apr 2016 14:29:46 -0000 On 18 Apr 2016, at 4:33, Magnus Westerlund wrote: > Hi Samuel, > > (CC the WG) > > Thanks for the review. > > Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> >> I am mostly satisfied with this document's security analysis. I am >> worried that implementors will weasel their way around the "SHOULD"s, >> but the appropriate "SHOULD"s are in the doc. >> >> The doc says "...there SHOULD be strong integrity protection and >> source >> authentication of the header extensions" -- I would like to also see >> specific citation(s). (e.g. "Use X for integrity protection." "Use >> X >> for authenticity.") > > So I will claim that the common problem that exists with minor RTP > extension and RTP payload formats (see RFC 7202) do apply here, we > should at least reference RFC 7201 for the options in the security > consideration section. > > I will edit our source and likely push out such a change quite soon so > that it is in place in good time before the IESG call. Unless our AD > objects. > > I propose to add the below to end of the last paragraph. > > "For information regarding options for securing RTP, see [RFC7201]." > > And add RFC7201 as an informative reference. The AD does not object. I think it makes sense to treat this similarly to how we treat payload drafts. > >> >> It would be nice to see some discussion of whether these headers >> increase the utility of RTP as a DOS vector - either by enabling a >> reflector attack or by triggering heavy computation on a receiving >> host. I suspect that there's not much to see here, particularly if >> there really is integrity protection, but it would be nice to see the >> analysis. > > Yes, this is a reasonable thing to consider. I suggest that we add the > below paragraph before the last paragraph in the Security > Consideration. > > The general RTP header extension mechanism does not itself contain any > functionality that is a significant risk for a denial of service > attack, nor from processing or storage requirements. This specific > extension for SDES items, could potentially be a risk. Do you mean that _this_ extension might be a risk, or that any specific SDES item might be a risk? The sentence sounds like it means the former, but the rest of the paragraph suggests the latter. > If the received SDES item and its content causes the receiver to > perform larger amount of processing, create significant storage > structures, or emit more network traffic such a risk do exist. The > CNAME SDES item is only a minor risk as reception of a CNAME item will > create an association between the stream carrying the SDES item and > other RTP streams with the same SDES item. As this can result in time > synchronizing the media streams some additional processing may result. > However, the applications media quality appear will be likely more > affected of the wrongly or changing association, than from the impact > caused by the additional processing. > > > >> [...] From nobody Tue Apr 19 01:03: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 8B10612DCCA; Tue, 19 Apr 2016 01:03:25 -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 LnKCbJ51_F5w; Tue, 19 Apr 2016 01:03:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9FD12DDEE; Tue, 19 Apr 2016 01:03:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-c8-5715e646c5fe Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.38.26920.646E5175; Tue, 19 Apr 2016 10:03:18 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.248.2; Tue, 19 Apr 2016 10:03:05 +0200 To: Ben Campbell References: <5714A9D6.4010602@ericsson.com> <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> From: Magnus Westerlund Message-ID: <5715E637.7070004@ericsson.com> Date: Tue, 19 Apr 2016 10:03:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <6A8437B6-9F42-4293-96AC-6FCE3D8DCD91@nostrum.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7ja7bM9FwgzU7FSw+3rvBajG/8zS7 xYwpB5gtZvyZyGzxYeFDFosJr6czObB5LFnyk8lj1s4nLB5LG3azBzBHcdmkpOZklqUW6dsl cGVMmtPCVnBRsWLz2aNsDYz/pLoYOTkkBEwkFh9ZwgJhi0lcuLeerYuRi0NI4AijxIuLW1kh nOWMElf3XQSrEhawkTh77yo7iC0ioCTxvHkrC0TRLEaJg2+7wRxmgWWMElvnb2MGqWITsJC4 +aORDcTmFdCWeLPjMiOIzSKgKnG77R9YXFQgRqLxwSkmiBpBiZMzn4Bt4xSwl/h2bCnQGRxA Q+0lHmwtAwkzC8hLNG+dDTZeCGhkQ1MH6wRGwVlIumchdMxC0rGAkXkVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmCIH9zyW3cH4+rXjocYBTgYlXh4FSaKhguxJpYVV+YeYpTgYFYS4Q17 DBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOmxP5L0xIID2xJDU7NbUgtQgmy8TBKdXAKFP/fE1u 0K1bvRktqdUNFtfkeNwOZSydYMIYk1HKUP/orPSlm7ZxOd3NBy65lNhJa8UZ/n3t/Pq96YzJ J56lXljFsENGeWIN5/xVvTc//dtw5OnDznmh8WxvjtrduWvLqlOau91Ocf3jf4vXFc/hflfN Yie3fGO1h3NUO5fSmtUnZqSrTvVWVWIpzkg01GIuKk4EABEFE9VtAgAA Archived-At: Cc: iesg@ietf.org, draft-ietf-avtext-sdes-hdr-ext.all@ietf.org, "avtext@ietf.org" , Samuel Weiler , secdir@ietf.org Subject: Re: [avtext] secdir review of draft-ietf-avtext-sdes-hdr-ext X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 08:03:25 -0000 Den 2016-04-18 kl. 16:29, skrev Ben Campbell: > On 18 Apr 2016, at 4:33, Magnus Westerlund wrote: > >> Hi Samuel, >> >> (CC the WG) >> >> Thanks for the review. >> >> Den 2016-04-17 kl. 13:45, skrev Samuel Weiler: >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> >>> I am mostly satisfied with this document's security analysis. I am >>> worried that implementors will weasel their way around the "SHOULD"s, >>> but the appropriate "SHOULD"s are in the doc. >>> >>> The doc says "...there SHOULD be strong integrity protection and source >>> authentication of the header extensions" -- I would like to also see >>> specific citation(s). (e.g. "Use X for integrity protection." "Use X >>> for authenticity.") >> >> So I will claim that the common problem that exists with minor RTP >> extension and RTP payload formats (see RFC 7202) do apply here, we >> should at least reference RFC 7201 for the options in the security >> consideration section. >> >> I will edit our source and likely push out such a change quite soon so >> that it is in place in good time before the IESG call. Unless our AD >> objects. >> >> I propose to add the below to end of the last paragraph. >> >> "For information regarding options for securing RTP, see [RFC7201]." >> >> And add RFC7201 as an informative reference. > > The AD does not object. I think it makes sense to treat this similarly > to how we treat payload drafts. > > >> >>> >>> It would be nice to see some discussion of whether these headers >>> increase the utility of RTP as a DOS vector - either by enabling a >>> reflector attack or by triggering heavy computation on a receiving >>> host. I suspect that there's not much to see here, particularly if >>> there really is integrity protection, but it would be nice to see the >>> analysis. >> >> Yes, this is a reasonable thing to consider. I suggest that we add the >> below paragraph before the last paragraph in the Security Consideration. >> >> The general RTP header extension mechanism does not itself contain any >> functionality that is a significant risk for a denial of service >> attack, nor from processing or storage requirements. This specific >> extension for SDES items, could potentially be a risk. > > Do you mean that _this_ extension might be a risk, or that any specific > SDES item might be a risk? The sentence sounds like it means the former, > but the rest of the paragraph suggests the latter. So the SDES item header extension in its basic mechanism does not appear to be a risk. However, the semantics of the SDES item itself may be a cause for concerns. It is really the next sentence below that attempts to clarify from where this risk comes. I will try to wordsmith this with help of my co-authors. > >> If the received SDES item and its content causes the receiver to >> perform larger amount of processing, create significant storage >> structures, or emit more network traffic such a risk do exist. The >> CNAME SDES item is only a minor risk as reception of a CNAME item will >> create an association between the stream carrying the SDES item and >> other RTP streams with the same SDES item. As this can result in time >> synchronizing the media streams some additional processing may result. >> However, the applications media quality appear will be likely more >> affected of the wrongly or changing association, than from the impact >> caused by the additional processing. >> 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 Sat Apr 23 07:58: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 4B84B12D178 for ; Sat, 23 Apr 2016 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[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=-0.996, 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 OKDdmRXfR8Us for ; Sat, 23 Apr 2016 07:58: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 B98ED12D128 for ; Sat, 23 Apr 2016 07:58:24 -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 CIG42548; Sat, 23 Apr 2016 14:58:22 +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; Sat, 23 Apr 2016 15:58:20 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Sat, 23 Apr 2016 22:58:11 +0800 From: "Huangyihong (Rachel)" To: "Huangyihong (Rachel)" , "avtext@ietf.org" Thread-Topic: call for adoption of draft-wenger-avtext-avpf-ccm-layered Thread-Index: AdGUZRQu3nbG30cwRZCPB3sk/HqHtgJCyWxw Date: Sat, 23 Apr 2016 14:58:10 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EA44BF@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86EA0418@nkgeml513-mbx.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86EA0418@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.46.3.77] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA44BFnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.571B8D8E.00BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 51e94ebf0d9d7b399ef801e9c42b932f Archived-At: Subject: Re: [avtext] call for adoption of draft-wenger-avtext-avpf-ccm-layered X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 14:58:28 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA44BFnkgeml513mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBzZWUgbm8gb2JqZWN0aW9uIHRvIGFkb3B0IHRoaXMgYXMgYSBuZXcgd29yayBpdGVtLiBCYXNl IG9uIHRoZSBjb25zZW5zdXMgaW4gdGhlIG1lZXRpbmcuIFRoaXMgd29yayBoYXMgYmVlbiBhZG9w dGVkLg0KDQoNCkJSLA0KUmFjaGVsDQoNCreivP7IyzogYXZ0ZXh0IFttYWlsdG86YXZ0ZXh0LWJv dW5jZXNAaWV0Zi5vcmddILT6se0gSHVhbmd5aWhvbmcgKFJhY2hlbCkNCreiy83KsbzkOiAyMDE2 xOo01MIxMsjVIDEwOjQzDQrK1bz+yMs6IGF2dGV4dEBpZXRmLm9yZw0K1vfM4jogW2F2dGV4dF0g Y2FsbCBmb3IgYWRvcHRpb24gb2YgZHJhZnQtd2VuZ2VyLWF2dGV4dC1hdnBmLWNjbS1sYXllcmVk DQoNCkRlYXIgYWxsLA0KDQpUaGlzIGRyYWZ0IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgQnVl bm9zIEFpcmVzIG1lZXRpbmcsIGFuZCB0aGVyZSB3YXMgY29uc2Vuc3VzIHRvIGFkb3B0IGl0IGFz IGEgd29yayBpdGVtLCBidXQgc3ViamVjdCB0byB0aGUgY29uZmlybWF0aW9uIG9uIHRoZSBsaXN0 LiBTbyBsZXShr3MgZ2V0IGl0IGRvbmU6DQoNClBsZWFzZSByZXNwb25kIHRvIGluZGljYXRlIGlm IHlvdSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv IGRyYWZ0LXdlbmdlci1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZCBhcyBhIHdvcmtpbmcgZ3JvdXAg d29yayBpdGVtLiBBbmQgcGxlYXNlIHJlc3BvbmQgaXQgYmVmb3JlIEFwcmlsIDIydGgsIDIwMTYu IFRoYW5rcy4NCg0KQlIsDQpSYWNoZWwNCg0K --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA44BFnkgeml513mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I see n= o objection to adopt this as a new work item. Base on the consensus in the = meeting. This work has been adopted.

&n= bsp;

&n= bsp;

BR,

Rachel<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: avtext [mailto:avtext-bounces@ietf.org] =B4=FA=B1=ED = Huangyihong (Rachel)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2016=C4=EA4=D4=C2<= span lang=3D"EN-US">12=C8=D5 10:43
=CA=D5=BC=FE=C8=CB: avtext@ietf.org
=D6=F7=CC=E2: [avtext] call for adoption of draft-wenger-avtext-avpf-ccm-layered

 

Dear all,

 

This draft has been discussed i= n the Buenos Aires meeting, and there was consensus to adopt it as a work i= tem, but subject to the confirmation on the list. So let=A1=AFs get it done= :

 

Please respond to indicate if y= ou support the adoption of https://tools.ietf.org/html/ d= raft-wenger-avtext-avpf-ccm-layered as a working group work item. And pleas= e respond it before April 22th, 2016. Thanks.

 

BR,

Rachel

 

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA44BFnkgeml513mbxchi_-- From nobody Sat Apr 23 09:24:09 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 A0D8F12D0C1 for ; Sat, 23 Apr 2016 09:24:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160423162408.2373.75110.idtracker@ietfa.amsl.com> Date: Sat, 23 Apr 2016 09:24:08 -0700 From: IETF Secretariat Archived-At: Subject: [avtext] Milestones changed for avtext WG X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Apr 2016 16:24:08 -0000 Changed milestone "Submit Update to Codec Control Messages in the RTP Audio-Visual Profile with Feedback (RFC5104) with Layered Codecs as Proposed Standard", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/avtext/charter/ From nobody Mon Apr 25 09:46: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 961BE12D625 for ; Mon, 25 Apr 2016 09:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 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=-0.996, 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 5dgoDTTakCRB for ; Mon, 25 Apr 2016 09:46:30 -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 8480812D5D7 for ; Mon, 25 Apr 2016 09:46:30 -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 CNE45699; Mon, 25 Apr 2016 16:46:27 +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; Mon, 25 Apr 2016 17:46:24 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.56]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 26 Apr 2016 00:46:18 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] draft-wenger-avtext-avpf-ccm-layered is adopted Thread-Index: AdGfEf2NyO1LcmeiTrG9mA4LargS2w== Date: Mon, 25 Apr 2016 16:46:18 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EA4B11@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.217.90] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA4B11nkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.571E49E3.0221, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: db52013272b4af4fa59958bba2bc3377 Archived-At: Subject: [avtext] draft-wenger-avtext-avpf-ccm-layered is adopted 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, 25 Apr 2016 16:46:32 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA4B11nkgeml513mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all This draft has been adopted. Authors, please submit 00 version for this wor= k item. Thanks. BR, Rachel --_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA4B11nkgeml513mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

This draft has been adopted. Au= thors, please submit 00 version for this work item. Thanks.

 

BR,

Rachel

--_000_51E6A56BD6A85142B9D172C87FC3ABBB86EA4B11nkgeml513mbxchi_-- From nobody Mon Apr 25 22:11: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 B432812D09B; Mon, 25 Apr 2016 22:11:31 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426051131.30250.25884.idtracker@ietfa.amsl.com> Date: Mon, 25 Apr 2016 22:11:31 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-avpf-ccm-layered-00.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, 26 Apr 2016 05:11:31 -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 : Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs Authors : Stephan Wenger Jonathan Lennox Bo Burman Magnus Westerlund Filename : draft-ietf-avtext-avpf-ccm-layered-00.txt Pages : 11 Date : 2016-04-25 Abstract: This document fixes a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) as defined in RFC5104 when using with layered codecs. In particular, a Decoder Refresh Point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-avpf-ccm-layered/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-avpf-ccm-layered-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 26 05:55:16 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 4A82712D1BC; Tue, 26 Apr 2016 05:55:13 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426125513.29054.51279.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 05:55:13 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-avtext-sdes-hdr-ext-05=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: Tue, 26 Apr 2016 12:55:13 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-avtext-sdes-hdr-ext-05: 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: ---------------------------------------------------------------------- This is a very clear and well written doc. Thanks. Two minor comments: 1) The calculation for the number of transmission N seems slightly over-complicated: "N is selected so that the header extension target delivery probability reaches 1-P^N, where P is the probability of packet loss." Does a new participant already know the loss probably e.g. at the time of joining? Is it correct that if it is assumed to be p=0 that one will send the extension header only once? Should there be a minimum...? 2) Should this doc also register MID? From nobody Tue Apr 26 06:13:09 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 90FED12B04F; Tue, 26 Apr 2016 06:13:05 -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.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426131305.29062.24789.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 06:13:05 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 13:13:05 -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-06.txt Pages : 16 Date : 2016-04-26 Abstract: Source Description (SDES) items are normally transported in RTP control protocol (RTCP). In some cases it can be beneficial to speed up the delivery of these items. Mainly when a new source (SSRC) joins an RTP session and the receivers needs this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 26 06:23: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 9619212D163; Tue, 26 Apr 2016 06:23:14 -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 UuH7c6JYIEYb; Tue, 26 Apr 2016 06:23:09 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1CE12D1C0; Tue, 26 Apr 2016 06:23:06 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-1f-571f6bb9f69f Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AB.CB.27088.9BB6F175; Tue, 26 Apr 2016 15:23:05 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.248.2; Tue, 26 Apr 2016 15:22:29 +0200 To: "avtext@ietf.org" , IESG References: <20160426131305.29062.24789.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <571F6B92.7090502@ericsson.com> Date: Tue, 26 Apr 2016 15:22:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160426131305.29062.24789.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUyM2K7me7ObPlwg98PhS0+3rvBajHjz0Rm ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl3DvSylTQJVbxbvYt1gbGfsEuRk4OCQETiTc3NrJB 2GISF+6tB7OFBI4wShyf4dXFyAVkL2eU+P1nAjtIQljATmL9+TmsXYwcHCICthKvFqtA1DtK 7JzWDFbCJmAhcfNHI9gcXgFtiZ39J1lAbBYBVYldCy+D2aICMRKND04xQdQISpyc+YQFZCSn gJPEp7WcICazgL3Eg61lIBXMAvISzVtnM0Ns0pZoaOpgncAoMAtJ8yyEjllIOhYwMq9iFC1O LU7KTTcy0kstykwuLs7P08tLLdnECAzCg1t+G+xgfPnc8RCjAAejEg/vgtNy4UKsiWXFlbmH GCU4mJVEeK9kyYcL8aYkVlalFuXHF5XmpBYfYpTmYFES582O/BcmJJCeWJKanZpakFoEk2Xi 4JRqYIz9kynKXdLxW25/+rtJW1lnaT/iqbm8+o3989MtWqfSxYOr3ivMLpimtvnv8oqdjE/V tEOPJyg43NTzf/nFIKt8+efHLx6nec/5uJbvZ0OSmefSpTPmnVPm8Xjwjft4usIhoZ7nf3ac v+Lq8ybw+8XcGYr77v7JbN2zbq67fRtnSEdNyM/NfFZKLMUZiYZazEXFiQDSoYR8PgIAAA== Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-sdes-hdr-ext-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 13:23:14 -0000 WG and IESG, With AD approval I have submitted an new version to address the Secdir comments. The main change is a new paragraph in the Security section regarding Denial of Service potentials from this header extensions. Cheers Magnus Den 2016-04-26 kl. 15:13, skrev internet-drafts@ietf.org: > > 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-06.txt > Pages : 16 > Date : 2016-04-26 > > Abstract: > Source Description (SDES) items are normally transported in RTP > control protocol (RTCP). In some cases it can be beneficial to speed > up the delivery of these items. Mainly when a new source (SSRC) > joins an RTP session and the receivers needs this source's identity, > relation to other sources, or its synchronization context, all of > which may be fully or partially identified using SDES items. To > enable this optimization, this document specifies a new RTP header > extension that can carry SDES items. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-sdes-hdr-ext-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-sdes-hdr-ext-06 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Apr 26 06:31:05 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 D125E12D130; Tue, 26 Apr 2016 06:30: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_H4=-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 7uiESeL7F1Ov; Tue, 26 Apr 2016 06:30:58 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A60A12B012; Tue, 26 Apr 2016 06:30:57 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-33-571f6d8ee834 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id ED.6C.18043.E8D6F175; Tue, 26 Apr 2016 15:30:54 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Tue, 26 Apr 2016 15:30:25 +0200 To: Mirja Kuehlewind , The IESG References: <20160426125513.29054.51279.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <571F6D6F.5080103@ericsson.com> Date: Tue, 26 Apr 2016 15:30:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160426125513.29054.51279.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7om5frny4wcdVehbt506wWHy8d4PV 4vaaT2wWM/5MZLZ4cf0js8X+xeeZHdg8liz5yeTR8nEhq0fbszvsAcxRXDYpqTmZZalF+nYJ XBlzpq9jKfglUtHfvoK9gXGFYBcjJ4eEgInEopX32SBsMYkL99YD2VwcQgJHGCX+L7/MBOEs Z5R4srCFFcQRFmhhlHi07ANzFyMHh4iAi8Tsr5wg3UICjhK3j7wAq2EWaGKUmPd8AthYNgEL iZs/GtlA6nkFtCUWTioFCbMIqEpcPHmPGcQWFYiRaHxwignE5hUQlDg58wkLiM0p4CSxa81p sDHMQGNmzj/PCGHLSzRvnc0MsVdboqGpg3UCo+AsJO2zkLTMQtKygJF5FaNocWpxcW66kZFe alFmcnFxfp5eXmrJJkZgiB/c8ttqB+PB546HGAU4GJV4eBeclgsXYk0sK67MPcQowcGsJMJ7 JUs+XIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvTuS/MCGB9MSS1OzU1ILUIpgsEwenVANjYrjB ec8JG916W38nKHzpDNbw0dFcFH7y6Mu8zm/CrFwf+Vgf/3qXqhqYfIqlduo8gyad9KCjLF9U Qhbt+rxZedns97s9Hz34G2CwZrP3D6WzoTvu6XZ8FevcdlfGvsJ0s8PkVNv8ewuPiopy+OT+ UVjLKJlyS7LtxsnpuYvs7abm3Ju8OspeiaU4I9FQi7moOBEAmDHRjm0CAAA= Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-avtext-sdes-hdr-ext-05=3A_=28with_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: Tue, 26 Apr 2016 13:31:00 -0000 Den 2016-04-26 kl. 14:55, skrev Mirja Kuehlewind: > Mirja Kühlewind has entered the following ballot position for > draft-ietf-avtext-sdes-hdr-ext-05: 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: > ---------------------------------------------------------------------- > > This is a very clear and well written doc. Thanks. Two minor comments: > > 1) The calculation for the number of transmission N seems slightly > over-complicated: "N is selected so that the header extension target > delivery probability reaches 1-P^N, where P is the probability of packet > loss." Does a new participant already know the loss probably e.g. at the > time of joining? Is it correct that if it is assumed to be p=0 that one > will send the extension header only once? Should there be a minimum...? So a new one may not know the probability of losses. But, assuming an active session a participant should have some data for the session quite rapidly, within a couple of RTCP reporting intervals. What could be done it to recommend a default value. However, we have to remember that a single transmission might be a very reasonable choice for scenarios with low loss probabilities, as one anyway have RTCP as the backup mechanism. Additional feedback is appreciated here. > > 2) Should this doc also register MID? Nope, as this document now has overtaken https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ it will be BUNDLE that has to define the registration. Initially we thought that BUNDLE would be done, and we would catch up and have to move the registration, but that didn't happen. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue Apr 26 07:10:56 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F812D1D4 for ; Tue, 26 Apr 2016 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, 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 bzb4u8e9Pwtj for ; Tue, 26 Apr 2016 07:10:48 -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 07A4812D1B2 for ; Tue, 26 Apr 2016 07:10:47 -0700 (PDT) Received: (qmail 5645 invoked from network); 26 Apr 2016 16:10:44 +0200 Received: from p5dec2f19.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.47.25) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 26 Apr 2016 16:10:44 +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: <571F6D6F.5080103@ericsson.com> Date: Tue, 26 Apr 2016 16:10:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160426125513.29054.51279.idtracker@ietfa.amsl.com> <571F6D6F.5080103@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, avtext-chairs@ietf.org, The IESG , draft-ietf-avtext-sdes-hdr-ext@ietf.org Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-avtext-sdes-hdr-ext-05=3A_=28with_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: Tue, 26 Apr 2016 14:10:54 -0000 Hi Magnus, see below. > Am 26.04.2016 um 15:30 schrieb Magnus Westerlund = : >=20 > Den 2016-04-26 kl. 14:55, skrev Mirja Kuehlewind: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-avtext-sdes-hdr-ext-05: 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-sdes-hdr-ext/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> This is a very clear and well written doc. Thanks. Two minor = comments: >>=20 >> 1) The calculation for the number of transmission N seems slightly >> over-complicated: "N is selected so that the header extension target >> delivery probability reaches 1-P^N, where P is the probability of = packet >> loss." Does a new participant already know the loss probably e.g. at = the >> time of joining? Is it correct that if it is assumed to be p=3D0 that = one >> will send the extension header only once? Should there be a = minimum...? >=20 > So a new one may not know the probability of losses. But, assuming an = active session a participant should have some data for the session quite = rapidly, within a couple of RTCP reporting intervals. What could be done = it to recommend a default value. However, we have to remember that a = single transmission might be a very reasonable choice for scenarios with = low loss probabilities, as one anyway have RTCP as the backup mechanism. >=20 > Additional feedback is appreciated here. I don=E2=80=99t have a good proposal here. I mainly wanted to make sure = that 1 is an acceptable value. I think it=E2=80=99s okay to leave it as = it is. >=20 >>=20 >> 2) Should this doc also register MID? >=20 > Nope, as this document now has overtaken = https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/= it will be BUNDLE that has to define the registration. Initially we = thought that BUNDLE would be done, and we would catch up and have to = move the registration, but that didn't happen. Okay. Didn=E2=80=99t see that it also defines the RTP extension. = That=E2=80=99s fine. Thanks, Mirja >=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 From nobody Tue Apr 26 07:32: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 B11F612D10E for ; Tue, 26 Apr 2016 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 YnjbJJq8WLYb for ; Tue, 26 Apr 2016 07:32:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96B112D1DF for ; Tue, 26 Apr 2016 07:32:17 -0700 (PDT) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.477.8; Tue, 26 Apr 2016 14:32:15 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0477.012; Tue, 26 Apr 2016 14:32:15 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-avpf-ccm-layered-00.txt Thread-Index: AQHRn3ob10sn15AHEUeWkFaGRF6dbp+b3IuA Date: Tue, 26 Apr 2016 14:32:14 +0000 Message-ID: References: <20160426051131.30250.25884.idtracker@ietfa.amsl.com> In-Reply-To: <20160426051131.30250.25884.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-ms-office365-filtering-correlation-id: 81fd2665-eee5-4476-81a6-08d36ddf9036 x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:LJ6Wdq7othCzZDOP0ks63HTy4vj5f4IXiPQIJyOEgys2yWUt37IjIaKStQw9zkdLUI8jamYgRMllee1ddGpoECfe8FzGkOPg4O77/dELplT7v9AtROJWeWHHemOLamGSYzr6z+05pYIUvgcjpo+Hhg==; 24:kvJTtCchrRTR+1bq3fZuxtG0++KfSaM34jycgToK8IKpmPfbBJLa1TF9GLmzQGuApst1RiudeQlA8yIJXunnvZDBRePRmdApLVQeZmJSi9g=; 7:BLYW8mtXE6vYfQBT953fjuOrwULN69xhVsLcKJxPCH26O5BUv9mFtfeT99L4UPpeHXZlrqfrEo29FTSdgLpFMjYhQrEugAyNGYjqGZOh91InFvNjzU9I5OhwcA3dc1p5u3umZha7OqeOXei8v0AHb7TiPkFLrp6hu5A8g6PCiU8D2RVKnHGNcsBJ0qBntmTr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(9101521072)(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274; x-forefront-prvs: 0924C6A0D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(53754006)(377424004)(86362001)(87936001)(1730700002)(122556002)(189998001)(33656002)(77096005)(5002640100001)(36756003)(230783001)(107886002)(81166005)(2501003)(10400500002)(5640700001)(3660700001)(2351001)(2950100001)(2900100001)(3846002)(15975445007)(11100500001)(102836003)(106116001)(82746002)(19580405001)(6116002)(19580395003)(5008740100001)(54356999)(92566002)(50986999)(586003)(2906002)(110136002)(99286002)(83716003)(3280700002)(66066001)(5004730100002)(1096002)(450100001)(1220700001)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2016 14:32:14.8841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274 Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-avpf-ccm-layered-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 14:32:19 -0000 SGkgYWxsLA0KVGhlIHN1Ym1pc3Npb24gYmVsb3cgaXMgdW5tb2RpZmllZCBmcm9tIHRoZSBpbmRp dmlkdWFsIGRyYWZ0IGV4Y2VwdCBmb3IgdGhlIGZpbGVuYW1lIGFuZCBkYXRlcy4gIFdlIHdpbGwg d29yayBvbiBhbm90aGVyIHZlcnNpb24gcmVmbGVjdGluZyB0aGUgZGlzY3Vzc2lvbiBpbiBCdWVu b3MgQWlyZXMgZXNwZWNpYWxseSB3aXRoIHJlc3BlY3QgdG8gdGhlIGluZGVudGlmaWNhdGlvbiBv ZiB0aGUgdXNlIG9mIGxheWVyZWQgY29kZWNzIGluIHNpbXVsY2FzdCBlbnZpcm9ubWVudHMuDQpT dGVwaGFuDQoNCg0KDQoNCg0KT24gNC8yNS8xNiwgMjI6MTEsICJhdnRleHQgb24gYmVoYWxmIG9m IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGF2dGV4dC1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQo+DQo+QSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KPlRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1ZGlvL1Zp ZGVvIFRyYW5zcG9ydCBFeHRlbnNpb25zIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICAgVGl0bGUg ICAgICAgICAgIDogVXNpbmcgQ29kZWMgQ29udHJvbCBNZXNzYWdlcyBpbiB0aGUgUlRQIEF1ZGlv LVZpc3VhbCBQcm9maWxlIHdpdGggRmVlZGJhY2sgd2l0aCBMYXllcmVkIENvZGVjcw0KPiAgICAg ICAgQXV0aG9ycyAgICAgICAgIDogU3RlcGhhbiBXZW5nZXINCj4gICAgICAgICAgICAgICAgICAg ICAgICAgIEpvbmF0aGFuIExlbm5veA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgQm8gQnVy bWFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBNYWdudXMgV2VzdGVybHVuZA0KPglGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGV4dC1hdnBmLWNjbS1sYXllcmVkLTAwLnR4dA0K PglQYWdlcyAgICAgICAgICAgOiAxMQ0KPglEYXRlICAgICAgICAgICAgOiAyMDE2LTA0LTI1DQo+ DQo+QWJzdHJhY3Q6DQo+ICAgVGhpcyBkb2N1bWVudCBmaXhlcyBhIHNob3J0Y29taW5nIGluIHRo ZSBzcGVjaWZpY2F0aW9uIGxhbmd1YWdlIG9mDQo+ICAgdGhlIENvZGVjIENvbnRyb2wgTWVzc2Fn ZSBGdWxsIEludHJhIFJlcXVlc3QgKEZJUikgYXMgZGVmaW5lZCBpbg0KPiAgIFJGQzUxMDQgd2hl biB1c2luZyB3aXRoIGxheWVyZWQgY29kZWNzLiAgSW4gcGFydGljdWxhciwgYSBEZWNvZGVyDQo+ ICAgUmVmcmVzaCBQb2ludCBuZWVkcyB0byBiZSBzZW50IGJ5IGEgbWVkaWEgc2VuZGVyIHdoZW4g YSBGSVIgaXMNCj4gICByZWNlaXZlZCBvbiBhbnkgbGF5ZXIgb2YgdGhlIGxheWVyZWQgYml0c3Ry ZWFtLCByZWdhcmRsZXNzIG9uIHdoZXRoZXINCj4gICB0aG9zZSBsYXllcnMgYXJlIGJlaW5nIHNl bnQgaW4gYSBzaW5nbGUgb3IgaW4gbXVsdGlwbGUgUlRQIGZsb3dzLg0KPiAgIFRoZSBvdGhlciBw YXlsb2FkLXNwZWNpZmljIGZlZWRiYWNrIG1lc3NhZ2VzIGRlZmluZWQgaW4gUkZDIDUxMDQgYW5k DQo+ICAgUkZDIDQ1ODUgYXMgdXBkYXRlZCBieSBSRkMgNTUwNiBoYXZlIGFsc28gYmVlbiBhbmFs eXplZCwgYW5kIG5vDQo+ICAgY29ycmVzcG9uZGluZyBzaG9ydGNvbWluZ3MgaGF2ZSBiZWVuIGZv dW5kLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRy YWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0 ZXh0LWF2cGYtY2NtLWxheWVyZWQvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lv biBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt YXZ0ZXh0LWF2cGYtY2NtLWxheWVyZWQtMDANCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+ dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu b255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmF2dGV4 dCBtYWlsaW5nIGxpc3QNCj5hdnRleHRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2F2dGV4dA0K From nobody Sat Apr 30 09:22:09 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 92CFA12D16A; Sat, 30 Apr 2016 09:22:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160430162207.31062.20470.idtracker@ietfa.amsl.com> Date: Sat, 30 Apr 2016 09:22:07 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] Alexey Melnikov's No Objection on draft-ietf-avtext-sdes-hdr-ext-06: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2016 16:22:07 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-avtext-sdes-hdr-ext-06: 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: ---------------------------------------------------------------------- The first mention of UTF-8 needs a reference. I am agreeing with Mirja about registering MID, as the document argues that it would be a good idea.