From nobody Mon Dec 1 06:53:38 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74D1A1BCD for ; Mon, 1 Dec 2014 06:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PejXy_9wuCk for ; Mon, 1 Dec 2014 06:53:35 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA871A0178 for ; Mon, 1 Dec 2014 06:53:35 -0800 (PST) Received: from [130.209.157.27] (port=2784 helo=glaroam2-168-225.wireless.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XvSM0-0001Zw-5n; Mon, 01 Dec 2014 14:53:33 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 1 Dec 2014 14:53:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/9kCZPP_9Aw39oXEMX03TdxzsN9w Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:53:37 -0000 I=92ve read this draft, and have a few generally minor comments. = Overall, though, I do think this draft is in very good shape. Section 2.1.10:=20 - =93Each RTP stream defines a unique RTP sequence numbering and timing = space=94 - should be =93each SSRC defines=94, since a change in SSRC = requires a new random offset to sequence number and timestamp. - Last two bullet points should perhaps be =93Several RTP Streams, each = with their own SSRC, =85=94 for clarity? Section 2.1.13: - =93Each transport association normally contains only a single RTP = session=85=94: agree, but it might be appropriate to mention that the = opposite isn=92t true, and RTP sessions can span multiple transport = associations. Figure 6: - The figure might benefit from having a =93synchronisation context=94 = included? Section 2.2.1: - Has an =93Editor=92s note=94 that should be removed Section 2.2.2: - Editor=92s note: I think it does make sense to talk about an RTP = session as a Communication Entity.=20 - The 4th bullet point is confusing. I think here, and also in section = 2.1.13, it might be clearer to say that a single media transport always = carries a single RTP session, and to describe = draft-westerlund-avtcore-transport-multiplexing as a way of carrying = multiple transport associations over a single port. - Last bullet point - can you give some examples? Section 2.2.3: - =93can have several multimedia sessions=94 -> =93can participate in=94 - =93Can have several associated=94 -> =93can be comprised of=94 Section 2.2.5: - This seems to prohibit a communication session with, e.g., just a = single audio flow. Section 3.1.4: - How does an m=3D line relate to the other terms defined here? Section 3.6: - =93Example to such codecs are=94 -> =93Examples of codecs that support = multi-channel audio are=94 Section 3.8: - Delete =93i.e., a different RTP session=94 just before Figure 8, since = the separate media transport is not necessarily part of a different RTP = session (although I agree it usually is). Cheers, Colin On 14 Nov 2014, at 17:31, DRAGE, Keith (Keith) = wrote: > (As WG cochair)=20 >=20 > This is to start a working group last call on = draft-ietf-avtext-rtp-grouping-taxonomy-03. >=20 > To cater for the end of the IETF meeting, and for various national = holidays, this working group last call will last three weeks. >=20 > Therefore please comment on this document by Friday 5th December 2014. >=20 > Please send comments to the working group list. >=20 > It is helpful to give some assessment of the nature of your comment, = as to whether you regard it as editorial, minor technical, or a rather = more major flaw. >=20 > Regards >=20 > Keith >=20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: 14 November 2014 12:05 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action: = draft-ietf-avtext-rtp-grouping-taxonomy-03.txt >=20 >=20 > 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 = Working Group of the IETF. >=20 > Title : A Taxonomy of Grouping Semantics and = Mechanisms for Real-Time Transport Protocol (RTP) Sources > Authors : Jonathan Lennox > Kevin Gross > Suhas Nandakumar > Gonzalo Salgueiro > Bo Burman > Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt > Pages : 42 > Date : 2014-11-14 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy= -03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ From nobody Mon Dec 1 23:58:10 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156DB1A0161 for ; Mon, 1 Dec 2014 23:58:09 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q89xrsYqLVAE for ; Mon, 1 Dec 2014 23:58:06 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4E81A015B for ; Mon, 1 Dec 2014 23:58:05 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-e5-547d710bb3e6 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 11.A3.24955.B017D745; Tue, 2 Dec 2014 08:58:03 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.198]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 08:58:02 +0100 From: Bo Burman To: "avtext@ietf.org" Thread-Topic: Resolving editor's note on "End Point" in RTP grouping taxonomy draft Thread-Index: AdANcy1ghIExnfAhTOSOExg/j09GzQ== Date: Tue, 2 Dec 2014 07:58:02 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E3DD3EFESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvjS53YW2IwYOtShYf791gtbjfs5nR Yn5XK6sDs8eSJT+ZPL5c/swWwBTFZZOSmpNZllqkb5fAlfFy0x/mgt7Qis45n1gaGJ95dTFy ckgImEise/2GDcIWk7hwbz2QzcUhJHCEUaJzzXcWCGcxo0Tb1bdgVWwCGhLzd9xlBLFFBNQl 7ky/ANbBLHCDUeLj7ItgCWGBAImWWeuYIYpCJW7+ms8OYetJfDz2HmwQi4CKxO81z8FqeAV8 JV53nwWzGQVkJe5/v8cCYjMLiEvcejKfCeI8AYkle84zQ9iiEi8f/2OFsBUlrk5fzgRRny+x ePdjRoiZghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyr GEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj6eCW36o7GC+/cTzEKMDBqMTD++FTTYgQa2JZ cWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMSltcfeWkwJ1nH/7t 9vef6xl+tjbao/T/1cby3wu2sJ+dapgroPrXgbtOXLJj3QsV4+bwdb7S4gxfV/0L0Hnx7vRM jSXmcTlMwtdn3Ty61ejYwSOn+A+V9/pt+dQz5frDJWf+VmtqJcx60Jr8RCtrfgXjL6k0/tag DIeDdQz+ppWB/+rv661RYinOSDTUYi4qTgQAOgMTQIcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/7mkWG4bZ0YXt9jXdaD7lTR5aTg4 Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" , "draft-ietf-avtcore-rtp-topologies-update@tools.ietf.org" Subject: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 07:58:09 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E3DD3EFESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There's an editor's note in draft-ietf-avtext-rtp-grouping-taxonomy-03 sect= ion 2.2.1 pondering whether the current "End Point" or the single-word "End= point" should be used as term. This editor's note needs to be resolved. I would like see this changed to the single-word term "Endpoint", since I b= elieve it is a more used term in RTP context (based on having searched thro= ugh various RTP-related documents), and I also believe the semantics in thi= s draft aligns well with the use of the term "endpoint" in those documents. To get a sense of the possible impact of this change to documents that refe= rences this draft, I have searched the IETF database for documents that bot= h references this draft and uses any form of "end point", "end-point" or "e= ndpoint". I can find only two documents that references the taxonomy draft,= uses any form of the term, and that are too far progressed to change; * draft-ietf-dart-dscp-rtp, uses the term "endpoint" (in RFC Ed Queue) * draft-ietf-payload-rtp-h265, uses "endpoint" (publication requested) I can only find two less progressed documents (omitting any pre-WG Last Cal= l documents) that references the taxonomy draft and that uses any form of t= he term; * draft-ietf-rtcweb-rtp-usage, uses "End-point" (WG consensus, waiting for writ= e-up) * draft-ietf-avtcore-rtp-topologies-update, uses "End Point" (in W= G Last Call) So, the only documents that are too far progressed to change both use the s= ingle-word form "endpoint", which is thus fully in line with my suggested c= hange. If you oppose this change for some reason, please speak up. If there are no= major objections, I will make this change in the next version. Cheers, Bo --_000_BBE9739C2C302046BD34B42713A1E2A22E3DD3EFESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There’s an editor’s note in draft-ietf-avtext-rtp-grouping-taxonomy-03 section 2.2.1 pondering whet= her the current “End Point” or the single-word “Endpoint&= #8221; should be used as term. This editor’s note needs to be resolve= d.

 

I would like see this changed to the single-word ter= m “Endpoint”, since I believe it is a more used term in RTP con= text (based on having searched through various RTP-related documents), and = I also believe the semantics in this draft aligns well with the use of the term “endpoint” in those documents.

 

To get a sense of the possible impact of this change= to documents that references this draft, I have searched the IETF database= for documents that both references this draft and uses any form of “= end point”, “end-point” or “endpoint”. I can find only two documents that references the taxonomy draft, uses any f= orm of the term, and that are too far progressed to change;

·         draft-ietf-dart-dscp-rtp, uses the term R= 20;endpoint” (in RFC Ed Queue)

·         draft-ietf-payload-rtp-h265, uses “= endpoint” (publication requested)

 

I can only find two less progressed documents (omitt= ing any pre-WG Last Call documents) that references the taxonomy draft and = that uses any form of the term;

·         draft-ietf-rtcweb-rtp-usage, uses ”= End-point” (WG consensus, waiting for write-up)

·         draft-ietf-avtcore-rtp-topologie= s-update, uses “End Point” (in WG Last Call)

 

So, the only documents that are too far progressed t= o change both use the single-word form “endpoint”, which is thu= s fully in line with my suggested change.

 

If you oppose this change for some reason, please sp= eak up. If there are no major objections, I will make this change in the ne= xt version.

 

Cheers,

Bo

 

--_000_BBE9739C2C302046BD34B42713A1E2A22E3DD3EFESESSMB105erics_-- From nobody Tue Dec 2 02:58:37 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736431A1A95 for ; Tue, 2 Dec 2014 02:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TOxypen8s6S for ; Tue, 2 Dec 2014 02:58:34 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854E41A1A93 for ; Tue, 2 Dec 2014 02:58:34 -0800 (PST) Received: from [130.209.247.112] (port=49420 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XvlA7-0007JI-J9; Tue, 02 Dec 2014 10:58:32 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB848FFB-8ADA-49B7-8719-F891C55F18E9" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Tue, 2 Dec 2014 10:58:21 +0000 Message-Id: References: To: Bo Burman X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/oWrduYlS2K3eum7leNdUj0-lFZ8 Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" , "avtext@ietf.org" , "draft-ietf-avtcore-rtp-topologies-update@tools.ietf.org" Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 10:58:36 -0000 --Apple-Mail=_FB848FFB-8ADA-49B7-8719-F891C55F18E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No objection on my part. I=92ll change the rtcweb-rtp-usage draft to = match the agreed term - let me know. Colin On 2 Dec 2014, at 07:58, Bo Burman wrote: > Hi, > =20 > There=92s an editor=92s note in = draft-ietf-avtext-rtp-grouping-taxonomy-03 section 2.2.1 pondering = whether the current =93End Point=94 or the single-word =93Endpoint=94 = should be used as term. This editor=92s note needs to be resolved. > =20 > I would like see this changed to the single-word term =93Endpoint=94, = since I believe it is a more used term in RTP context (based on having = searched through various RTP-related documents), and I also believe the = semantics in this draft aligns well with the use of the term =93endpoint=94= in those documents. > =20 > To get a sense of the possible impact of this change to documents that = references this draft, I have searched the IETF database for documents = that both references this draft and uses any form of =93end point=94, = =93end-point=94 or =93endpoint=94. I can find only two documents that = references the taxonomy draft, uses any form of the term, and that are = too far progressed to change; > =B7 draft-ietf-dart-dscp-rtp, uses the term =93endpoint=94 (in = RFC Ed Queue) > =B7 draft-ietf-payload-rtp-h265, uses =93endpoint=94 = (publication requested) > =20 > I can only find two less progressed documents (omitting any pre-WG = Last Call documents) that references the taxonomy draft and that uses = any form of the term; > =B7 draft-ietf-rtcweb-rtp-usage, uses =94End-point=94 (WG = consensus, waiting for write-up) > =B7 draft-ietf-avtcore-rtp-topologies-update, uses =93End = Point=94 (in WG Last Call) > =20 > So, the only documents that are too far progressed to change both use = the single-word form =93endpoint=94, which is thus fully in line with my = suggested change. > =20 > If you oppose this change for some reason, please speak up. If there = are no major objections, I will make this change in the next version. > =20 > Cheers, > Bo --Apple-Mail=_FB848FFB-8ADA-49B7-8719-F891C55F18E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 No = objection on my part. I=92ll change the rtcweb-rtp-usage draft to match = the agreed term - let me = know.

Colin


On 2 Dec = 2014, at 07:58, Bo Burman <bo.burman@ericsson.com> = wrote:

Hi,

 

There=92s an = editor=92s note in draft-ietf-avtext-rtp-grouping-taxonomy-03 section 2.2.1 pondering = whether the current =93End Point=94 or the single-word =93Endpoint=94 = should be used as term. This editor=92s note needs to be = resolved.

 

I would like see this changed to the single-word = term =93Endpoint=94, since I believe it is a more used term in RTP = context (based on having searched through various RTP-related = documents), and I also believe the semantics in this draft aligns well with the use of the term =93endpoint=94 in those = documents.

 

To get a sense of the possible impact of this change = to documents that references this draft, I have searched the IETF = database for documents that both references this draft and uses any form = of =93end point=94, =93end-point=94 or =93endpoint=94. I can find only two documents that references the taxonomy draft, uses = any form of the term, and that are too far progressed to = change;

=B7         draft-= ietf-dart-dscp-rtp, uses the term =93endpoint=94 (in RFC Ed = Queue)

=B7         dra= ft-ietf-payload-rtp-h265, uses =93endpoint=94 (publication = requested)

 

I can only find two less progressed documents = (omitting any pre-WG Last Call documents) that references the taxonomy = draft and that uses any form of the term;

=B7         dra= ft-ietf-rtcweb-rtp-usage, uses =94End-point=94 (WG consensus, = waiting for write-up)

=B7         draft-ietf-avtcore-rtp-topologies-update, uses =93End = Point=94 (in WG Last Call)

 

So, the = only documents that are too far progressed to change both use the = single-word form =93endpoint=94, which is thus fully in line with my = suggested change.

 

If you = oppose this change for some reason, please speak up. If there are no = major objections, I will make this change in the next = version.

 

Cheers,

Bo


= --Apple-Mail=_FB848FFB-8ADA-49B7-8719-F891C55F18E9-- From nobody Tue Dec 2 07:40:11 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7891A1BE3 for ; Tue, 2 Dec 2014 07:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71qj0F54r7_F for ; Tue, 2 Dec 2014 07:40:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D811A1BDD for ; Tue, 2 Dec 2014 07:40:01 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-14-547ddd4f586c Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7C.E7.24955.F4DDD745; Tue, 2 Dec 2014 16:39:59 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.198]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 16:39:59 +0100 From: Bo Burman To: Colin Perkins , "DRAGE, Keith (Keith)" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgBp7s4CAAY0RQA== Date: Tue, 2 Dec 2014 15:39:59 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7/3doQg/kvLCw+3rvBarH85QlG i6eNZxkdmD1an+1l9Zh2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4Mh6t38Bc8Cqo4sS7qywN jA02XYycHBICJhJLlq1hg7DFJC7cWw9kc3EICRxhlDg0bQsjhLOYUeLvuVksIFVsAhoS83fc ZQSxRQQSJB5cn8IKYjMLqEsc3rcELC4sECTR8bOfFaImWOLUplZ2CNtJ4uX342A2i4CKxLs5 /WD1vAK+Es9OX2KHWDaRUeJP33SwIk4BR4klb5+DLWYUkJW4//0eC8QycYlbT+YzQZwtILFk z3lmCFtU4uXjf6wQtpLEjw2XoOp1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYWkpZZ SFpmIWlZwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwrg5u+a26g/HyG8dDjAIcjEo8 vB8+1YQIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGP/WG PTqNaYcen/RbXDzbos4p7F1C6ifHg+lLvdvkGA8dFv3icVN14vss0+fZUuVvX537+L4iOaTu bvM+j7mi89Je6bXoKjwvMvht/sfiv+C5AG+WvFq15bP81Hm6Gza4RdiViT2/WTfxVrmbV2Zr 52mH7+v+Oa+eoxvhXjjr+9Rdf0OivUKUWIozEg21mIuKEwG1RsSsjAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/0nbP1NCBa87uGybrh5hszmYt3W0 Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 15:40:10 -0000 Hi Colin, Thank you for the review! Comments inline. Cheers, Bo > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Colin Perkins > Sent: den 1 december 2014 15:53 > To: DRAGE, Keith (Keith) > Cc: avtext@ietf.org > Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy= -03.txt >=20 > I've read this draft, and have a few generally minor comments. Overall, t= hough, I do think this draft is in very good shape. >=20 > Section 2.1.10: > - "Each RTP stream defines a unique RTP sequence numbering and timing spa= ce" - should be "each SSRC defines", since a > change in SSRC requires a new random offset to sequence number and timest= amp. [BoB] True. What about "Each SSRC (even for a single RTP stream, see above)= defines a unique..." to hopefully be even more clear in connecting that st= atement back to what applies to an RTP Stream? >=20 > - Last two bullet points should perhaps be "Several RTP Streams, each wit= h their own SSRC, ..." for clarity? [BoB] OK >=20 > Section 2.1.13: > - "Each transport association normally contains only a single RTP session= ...": agree, but it might be appropriate to mention > that the opposite isn't true, and RTP sessions can span multiple transpor= t associations. [BoB] Good idea. >=20 > Figure 6: > - The figure might benefit from having a "synchronisation context" includ= ed? [BoB] Maybe, but that is not part of the section where Figure 6 is included= ! I also have somewhat of a problem how to depict it, especially since I do= n't want the picture to become clobbered. Do you have any concrete proposal= in mind? A synchronization context is, in that picture, basically a grouping of some= (not necessarily all) individual RTP streams that are part of the indicate= d RTP sessions, carried by the indicated Media Transport(s), in a single di= rection. Such sample synchronization context can be a relation within a sin= gle Media Transport (which will be impossible to see without expanding the = Media Transport arrow), or (easier to depict) a relation stretching across = both indicated Media Transports, but at the same time not encompassing (no = box around) the entire Media Transport. One possible suggestion would be (not saying that I accepted to make this e= dit without at least some further discussion): +------------------------------------------------------------+ | Communication Session | | | | +----------------+ +----------------+ | | | Participant A | +------------+ | Participant B | | | | | | Multimedia | | | | | | +-------------+|<=3D=3D>| Session |<=3D=3D>|+-------------+ | = | | | | End Point A || | | || End Point B | | | | | | || +------------+ || | | | | | | +-----------++----------------------++-----------+ | | | | | | | | | | | | | | | | | RTP Session|---Media Transport--->| | | | | | | | | Audio |<---Media Transport---| | | | | | | | | | ^ | | | | | | | | +-----------++----------|-----------++-----------+ | | | | | | || v || | | | | | | || +-----------------+ || | | | | | | || | Synchronization | || | | | | | | || | Context | || | | | | | | || +-----------------+ || | | | | | | || ^ || | | | | | | +-----------++----------|-----------++-----------+ | | | | | | | | v | | | | | | | | | RTP Session|<---Media Transport---| | | | | | | | | Video |---Media Transport--->| | | | | | | | | | | | | | | | | | +-----------++----------------------++-----------+ | | | | | +-------------+| |+-------------+ | | | +----------------+ +----------------+ | +------------------------------------------------------------+ >=20 > Section 2.2.1: > - Has an "Editor's note" that should be removed [BoB] Yes. See separate mail thread on that topic. >=20 > Section 2.2.2: > - Editor's note: I think it does make sense to talk about an RTP session = as a Communication Entity. [BoB] Good. I do too, so I suggest to keep it here and remove the editor's = note. >=20 > - The 4th bullet point is confusing. I think here, and also in section 2.= 1.13, it might be clearer to say that a single media > transport always carries a single RTP session, and to describe draft-west= erlund-avtcore-transport-multiplexing as a way > of carrying multiple transport associations over a single port. [BoB] Agree that this is probably a useful distinction to make. This will r= equire a few text changes in both 2.1.13 and here in 2.2.2. I actually sugg= est that we describe that type of multiplexing only in 2.1.13 and keep sile= nt about it in 2.2.2, only mentioning that a single Media Transport cannot = carry more than a single RTP session. >=20 > - Last bullet point - can you give some examples? [BoB] I realize that "related" can there be taken to mean either conceptual= ly related, for example originating from or targeted for the same endpoint = or participant, or (implicitly) by containing RTP streams that are somehow = related (synchronization context, dependency, redundancy, etc), or it can b= e taken as a suggestion that there exist some defined RTP session "handle" = allowing for more concrete relation actions, which is in general not true. I wonder if the very brief text in this bullet is in fact redundant, suffic= iently discussed in section 3, and could be deleted here? >=20 > Section 2.2.3: > - "can have several multimedia sessions" -> "can participate in" > - "Can have several associated" -> "can be comprised of" [BoB] OK >=20 > Section 2.2.5: > - This seems to prohibit a communication session with, e.g., just a singl= e audio flow. [BoB] That was not the intent. I will clarify. >=20 > Section 3.1.4: > - How does an m=3D line relate to the other terms defined here? [BoB] I think that is elaborated in the existing term description section 4= .2 "Media Description". I can cross reference that section here. Do you thi= nk that is sufficient, or do you want a more elaborate description here too= ? >=20 > Section 3.6: > - "Example to such codecs are" -> "Examples of codecs that support multi-= channel audio are" [BoB] OK >=20 > Section 3.8: > - Delete "i.e., a different RTP session" just before Figure 8, since the = separate media transport is not necessarily part of a > different RTP session (although I agree it usually is). [BoB] OK >=20 > Cheers, > Colin >=20 >=20 >=20 >=20 >=20 > On 14 Nov 2014, at 17:31, DRAGE, Keith (Keith) wrote: >=20 > > (As WG cochair) > > > > This is to start a working group last call on draft-ietf-avtext-rtp-gro= uping-taxonomy-03. > > > > To cater for the end of the IETF meeting, and for various national holi= days, this working group last call will last three > weeks. > > > > Therefore please comment on this document by Friday 5th December 2014. > > > > Please send comments to the working group list. > > > > It is helpful to give some assessment of the nature of your comment, as= to whether you regard it as editorial, minor > technical, or a rather more major flaw. > > > > Regards > > > > Keith > > > > -----Original Message----- > > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of internet-dra= fts@ietf.org > > Sent: 14 November 2014 12:05 > > To: i-d-announce@ietf.org > > Cc: avtext@ietf.org > > Subject: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-0= 3.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > > This draft is a work item of the Audio/Video Transport Extensions Worki= ng Group of the IETF. > > > > Title : A Taxonomy of Grouping Semantics and Mechanism= s for Real-Time Transport Protocol (RTP) Sources > > Authors : Jonathan Lennox > > Kevin Gross > > Suhas Nandakumar > > Gonzalo Salgueiro > > Bo Burman > > Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt > > Pages : 42 > > Date : 2014-11-14 > > > > Abstract: > > The terminology about, and associations among, Real-Time Transport > > Protocol (RTP) sources can be complex and somewhat opaque. This > > document describes a number of existing and proposed relationships > > among RTP sources, and attempts to define common terminology for > > discussing protocol entities and their relationships. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonom= y/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxon= omy-03 > > > > > > Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are > available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue Dec 2 08:27:28 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3051A1BE4 for ; Tue, 2 Dec 2014 08:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E61l5sjG8eQq for ; Tue, 2 Dec 2014 08:27:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0117.outbound.protection.outlook.com [65.55.169.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2783E1A1EF0 for ; Tue, 2 Dec 2014 08:27:03 -0800 (PST) Received: from CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) by CY1PR0701MB1324.namprd07.prod.outlook.com (25.160.150.14) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 16:27:00 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 2 Dec 2014 16:26:58 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0026.003; Tue, 2 Dec 2014 16:26:58 +0000 From: Stephan Wenger To: Colin Perkins , Bo Burman Thread-Topic: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft Thread-Index: AQHQDh7vDGFl33JHV0SbZEYiJ4LagJx79ysA Date: Tue, 2 Dec 2014 16:26:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.124.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275;UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1275; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(199003)(54356999)(19580395003)(19580405001)(76176999)(68736005)(46102003)(92566001)(92726001)(2656002)(87936001)(15975445006)(86362001)(50986999)(40100003)(122556002)(62966003)(120916001)(99396003)(15187005004)(16236675004)(97736003)(77156002)(99286002)(107046002)(95666004)(106356001)(106116001)(105586002)(21056001)(101416001)(19625215002)(4396001)(31966008)(19617315012)(36756003)(66066001)(20776003)(64706001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0A328094C39Fstewesteweorg_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1324; X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/rHszYlFxkrAI03Z0Sc1d9SsyBWA Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" , "avtext@ietf.org" , "draft-ietf-avtcore-rtp-topologies-update@tools.ietf.org" Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 16:27:27 -0000 --_000_D0A328094C39Fstewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Same re topologies-update. (We actually changed it to "End Point" for alignment with the taxonomy draf= t in the first place.) Stephan From: Colin Perkins > Date: Tuesday, December 2, 2014 at 02:58 To: Bo Burman > Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" >, "avtext@ietf.org" >, "draft-ietf-avtcor= e-rtp-topologies-update@tools.ietf.org" > Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP groupin= g taxonomy draft No objection on my part. I'll change the rtcweb-rtp-usage draft to match th= e agreed term - let me know. Colin On 2 Dec 2014, at 07:58, Bo Burman > wrote: Hi, There's an editor's note in draft-ietf-avtext-rtp-grouping-taxonomy-03 sect= ion 2.2.1 pondering whether the current "End Point" or the single-word "End= point" should be used as term. This editor's note needs to be resolved. I would like see this changed to the single-word term "Endpoint", since I b= elieve it is a more used term in RTP context (based on having searched thro= ugh various RTP-related documents), and I also believe the semantics in thi= s draft aligns well with the use of the term "endpoint" in those documents. To get a sense of the possible impact of this change to documents that refe= rences this draft, I have searched the IETF database for documents that bot= h references this draft and uses any form of "end point", "end-point" or "e= ndpoint". I can find only two documents that references the taxonomy draft,= uses any form of the term, and that are too far progressed to change; =B7 draft-ietf-dart-dscp-rtp, uses the term "endpoint" (in RFC Ed Queue) =B7 draft-ietf-payload-rtp-h265, uses "endpoint" (publication requested) I can only find two less progressed documents (omitting any pre-WG Last Cal= l documents) that references the taxonomy draft and that uses any form of t= he term; =B7 draft-ietf-rtcweb-rtp-usage, uses "End-point" (WG consensus, waiting for wr= ite-up) =B7 draft-ietf-avtcore-rtp-topologies-update, uses "End Point" (in= WG Last Call) So, the only documents that are too far progressed to change both use the s= ingle-word form "endpoint", which is thus fully in line with my suggested c= hange. If you oppose this change for some reason, please speak up. If there are no= major objections, I will make this change in the next version. Cheers, Bo --_000_D0A328094C39Fstewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Same re topologies-update.
(We actually changed it to "End Point” for alignment with t= he taxonomy draft in the first place.)
Stephan

From: Colin Perkins <csp@csperkins.org>
Date: Tuesday, December 2, 2014 at = 02:58
To: Bo Burman <bo.burman@ericsson.com>
Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf= .org" <draft-ietf-rtcweb-rtp-usage@tools.ietf.org>, "avtext@ietf.org" <avtext@ietf.org>, "draft-ietf-a= vtcore-rtp-topologies-update@tools.ietf.org" <draft-ietf-avtcor= e-rtp-topologies-update@tools.ietf.org>
Subject: Re: [avtext] Resolving edi= tor's note on "End Point" in RTP grouping taxonomy draft

No objection on my part. I’ll change the rtcweb-rtp-usage draft to ma= tch the agreed term - let me know.

Colin


On 2 Dec 2014, at 07:58, Bo Burman <bo.burman@ericsson.com> wrote:

Hi,

 

There’s an editor’s note in draft-ietf-avtext-rtp-grouping-taxonomy-03 section 2.2.1 pondering whet= her the current “End Point” or the single-word “Endpoint&= #8221; should be used as term. This editor’s note needs to be resolve= d.

 

I would like see this changed to the single-word ter= m “Endpoint”, since I believe it is a more used term in RTP con= text (based on having searched through various RTP-related documents), and = I also believe the semantics in this draft aligns well with the use of the term “endpoint” in those documents.

 

To get a sense of the possible impact of this change= to documents that references this draft, I have searched the IETF database= for documents that both references this draft and uses any form of “= end point”, “end-point” or “endpoint”. I can find only two documents that references the taxonomy draft, uses any f= orm of the term, and that are too far progressed to change;

=B7         draft-ietf-dart-dscp-rtp, uses the term = “endpoint” (in RFC Ed Queue)

=B7         draft-ietf-payload-rtp-h265, uses = 220;endpoint” (publication requested)

 

I can only find two less progressed documents (omitt= ing any pre-WG Last Call documents) that references the taxonomy draft and = that uses any form of the term;

=B7         draft-ietf-rtcweb-rtp-usage, uses = 221;End-point” (WG consensus, waiting for write-up)

=B7         draft-ietf-avtcore-rtp-topol= ogies-update, uses “End Point” (in WG Last Call)=

 

So, the only documents that are too far progressed t= o change both use the single-word form “endpoint”, which is thu= s fully in line with my suggested change.

 

If you oppose this change for some reason, please sp= eak up. If there are no major objections, I will make this change in the ne= xt version.

 

Cheers,

Bo


 --_000_D0A328094C39Fstewesteweorg_-- From nobody Wed Dec 3 03:49:59 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B257B1A1A93 for ; Wed, 3 Dec 2014 03:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXV5TI73iQVz for ; Wed, 3 Dec 2014 03:49:56 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBF751A1A83 for ; Wed, 3 Dec 2014 03:49:55 -0800 (PST) Received: from [130.209.247.112] (port=63634 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Xw8RL-000238-Di; Wed, 03 Dec 2014 11:49:52 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Wed, 3 Dec 2014 11:49:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <89992EDF-E650-4785-AF81-A091D7FDE708@csperkins.org> References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: Bo Burman X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/3H8mF9kmWJTHB4tWaUbEIWnaHyw Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:49:58 -0000 Hi Bo, Comments inline. This basically all looks good. Cheers, Colin On 2 Dec 2014, at 15:39, Bo Burman wrote: > Hi Colin, >=20 > Thank you for the review! Comments inline. >=20 > Cheers, > Bo >=20 >> -----Original Message----- >> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Colin = Perkins >> Sent: den 1 december 2014 15:53 >> To: DRAGE, Keith (Keith) >> Cc: avtext@ietf.org >> Subject: Re: [avtext] I-D Action: = draft-ietf-avtext-rtp-grouping-taxonomy-03.txt >>=20 >> I've read this draft, and have a few generally minor comments. = Overall, though, I do think this draft is in very good shape. >>=20 >> Section 2.1.10: >> - "Each RTP stream defines a unique RTP sequence numbering and timing = space" - should be "each SSRC defines", since a >> change in SSRC requires a new random offset to sequence number and = timestamp. > [BoB] True. What about =93Each SSRC (even for a single RTP stream, see = above) defines a unique..." to hopefully be even more clear in = connecting that statement back to what applies to an RTP Stream? I don=92t think that clarifies, especially given the preceding bullet = point says that an RTP stream can have one and only one SSRC. The key = characteristic is that the SSRC has a single sequence number and = timestamp space; this is not true of an RTP stream, because the SSRC can = change. >> - Last two bullet points should perhaps be "Several RTP Streams, each = with their own SSRC, ..." for clarity? > [BoB] OK >=20 >>=20 >> Section 2.1.13: >> - "Each transport association normally contains only a single RTP = session...": agree, but it might be appropriate to mention >> that the opposite isn't true, and RTP sessions can span multiple = transport associations. > [BoB] Good idea. >=20 >>=20 >> Figure 6: >> - The figure might benefit from having a "synchronisation context" = included? > [BoB] Maybe, but that is not part of the section where Figure 6 is = included! I also have somewhat of a problem how to depict it, especially = since I don't want the picture to become clobbered. Do you have any = concrete proposal in mind? I was going to suggest another box surrounding the RTP Session Audio and = RTP Session Video, but I think your suggestion below is clearer. > A synchronization context is, in that picture, basically a grouping of = some (not necessarily all) individual RTP streams that are part of the = indicated RTP sessions, carried by the indicated Media Transport(s), in = a single direction. Such sample synchronization context can be a = relation within a single Media Transport (which will be impossible to = see without expanding the Media Transport arrow), or (easier to depict) = a relation stretching across both indicated Media Transports, but at the = same time not encompassing (no box around) the entire Media Transport. >=20 > One possible suggestion would be (not saying that I accepted to make = this edit without at least some further discussion): >=20 > +------------------------------------------------------------+ > | Communication Session | > | | > | +----------------+ +----------------+ | > | | Participant A | +------------+ | Participant B | | > | | | | Multimedia | | | | > | | +-------------+|<=3D=3D>| Session |<=3D=3D>|+-------------+ = | | > | | | End Point A || | | || End Point B | | | > | | | || +------------+ || | | | > | | | +-----------++----------------------++-----------+ | | | > | | | | | | | | | | > | | | | RTP Session|---Media Transport--->| | | | | > | | | | Audio |<---Media Transport---| | | | | > | | | | | ^ | | | | | > | | | +-----------++----------|-----------++-----------+ | | | > | | | || v || | | | > | | | || +-----------------+ || | | | > | | | || | Synchronization | || | | | > | | | || | Context | || | | | > | | | || +-----------------+ || | | | > | | | || ^ || | | | > | | | +-----------++----------|-----------++-----------+ | | | > | | | | | v | | | | | > | | | | RTP Session|<---Media Transport---| | | | | > | | | | Video |---Media Transport--->| | | | | > | | | | | | | | | | > | | | +-----------++----------------------++-----------+ | | | > | | +-------------+| |+-------------+ | | > | +----------------+ +----------------+ | > +------------------------------------------------------------+ This looks good to me. >> Section 2.2.1: >> - Has an "Editor's note" that should be removed > [BoB] Yes. See separate mail thread on that topic. >=20 >>=20 >> Section 2.2.2: >> - Editor's note: I think it does make sense to talk about an RTP = session as a Communication Entity. > [BoB] Good. I do too, so I suggest to keep it here and remove the = editor's note. >=20 >>=20 >> - The 4th bullet point is confusing. I think here, and also in = section 2.1.13, it might be clearer to say that a single media >> transport always carries a single RTP session, and to describe = draft-westerlund-avtcore-transport-multiplexing as a way >> of carrying multiple transport associations over a single port. > [BoB] Agree that this is probably a useful distinction to make. This = will require a few text changes in both 2.1.13 and here in 2.2.2. I = actually suggest that we describe that type of multiplexing only in = 2.1.13 and keep silent about it in 2.2.2, only mentioning that a single = Media Transport cannot carry more than a single RTP session. Makes sense. >> - Last bullet point - can you give some examples? > [BoB] I realize that "related" can there be taken to mean either = conceptually related, for example originating from or targeted for the = same endpoint or participant, or (implicitly) by containing RTP streams = that are somehow related (synchronization context, dependency, = redundancy, etc), or it can be taken as a suggestion that there exist = some defined RTP session "handle" allowing for more concrete relation = actions, which is in general not true. >=20 > I wonder if the very brief text in this bullet is in fact redundant, = sufficiently discussed in section 3, and could be deleted here? Or keep it, but add a forward reference to Section 3? >> Section 2.2.3: >> - "can have several multimedia sessions" -> "can participate in" >> - "Can have several associated" -> "can be comprised of" > [BoB] OK >=20 >>=20 >> Section 2.2.5: >> - This seems to prohibit a communication session with, e.g., just a = single audio flow. > [BoB] That was not the intent. I will clarify. >=20 >>=20 >> Section 3.1.4: >> - How does an m=3D line relate to the other terms defined here? > [BoB] I think that is elaborated in the existing term description = section 4.2 "Media Description". I can cross reference that section = here. Do you think that is sufficient, or do you want a more elaborate = description here too? No, a cross reference to Section 4.2 would be enough.=20 >> Section 3.6: >> - "Example to such codecs are" -> "Examples of codecs that support = multi-channel audio are" > [BoB] OK >=20 >>=20 >> Section 3.8: >> - Delete "i.e., a different RTP session" just before Figure 8, since = the separate media transport is not necessarily part of a >> different RTP session (although I agree it usually is). > [BoB] OK >=20 >>=20 >> Cheers, >> Colin >>=20 >>=20 >>=20 >>=20 >>=20 >> On 14 Nov 2014, at 17:31, DRAGE, Keith (Keith) = wrote: >>=20 >>> (As WG cochair) >>>=20 >>> This is to start a working group last call on = draft-ietf-avtext-rtp-grouping-taxonomy-03. >>>=20 >>> To cater for the end of the IETF meeting, and for various national = holidays, this working group last call will last three >> weeks. >>>=20 >>> Therefore please comment on this document by Friday 5th December = 2014. >>>=20 >>> Please send comments to the working group list. >>>=20 >>> It is helpful to give some assessment of the nature of your comment, = as to whether you regard it as editorial, minor >> technical, or a rather more major flaw. >>>=20 >>> Regards >>>=20 >>> Keith >>>=20 >>> -----Original Message----- >>> From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >>> Sent: 14 November 2014 12:05 >>> To: i-d-announce@ietf.org >>> Cc: avtext@ietf.org >>> Subject: [avtext] I-D Action: = draft-ietf-avtext-rtp-grouping-taxonomy-03.txt >>>=20 >>>=20 >>> 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 = Working Group of the IETF. >>>=20 >>> Title : A Taxonomy of Grouping Semantics and = Mechanisms for Real-Time Transport Protocol (RTP) Sources >>> Authors : Jonathan Lennox >>> Kevin Gross >>> Suhas Nandakumar >>> Gonzalo Salgueiro >>> Bo Burman >>> Filename : draft-ietf-avtext-rtp-grouping-taxonomy-03.txt >>> Pages : 42 >>> Date : 2014-11-14 >>>=20 >>> Abstract: >>> The terminology about, and associations among, Real-Time Transport >>> Protocol (RTP) sources can be complex and somewhat opaque. This >>> document describes a number of existing and proposed relationships >>> among RTP sources, and attempts to define common terminology for >>> discussing protocol entities and their relationships. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-grouping-taxonomy/ >>>=20 >>> There's also a htmlized version available at: >>> = http://tools.ietf.org/html/draft-ietf-avtext-rtp-grouping-taxonomy-03 >>>=20 >>> A diff from the previous version is available at: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rtp-grouping-taxonomy= -03 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are >> available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>>=20 >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>=20 >>=20 >>=20 >> -- >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ From nobody Wed Dec 3 04:57:56 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD71A1A17 for ; Wed, 3 Dec 2014 04:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wUFaETsatHv for ; Wed, 3 Dec 2014 04:57:52 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E3B1A1A99 for ; Wed, 3 Dec 2014 04:57:51 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-04-547f08cdc296 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.2C.04076.DC80F745; Wed, 3 Dec 2014 13:57:50 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.198]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 13:57:50 +0100 From: Bo Burman To: Colin Perkins Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgBp7s4CAAY0RQIABZEQAgAAcJdA= Date: Wed, 3 Dec 2014 12:57:48 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89992EDF-E650-4785-AF81-A091D7FDE708@csperkins.org> In-Reply-To: <89992EDF-E650-4785-AF81-A091D7FDE708@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje45jvoQg8W3uC0+3rvBarH85QlG i6eNZxkdmD1an+1l9Zh2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4MqbcWMJccEKlYs6pE2wN jK3SXYycHBICJhIPvq1igrDFJC7cW8/WxcjFISRwhFGic+0idpCEkMBiRonmG9YgNpuAhsT8 HXcZQWwRAVWJHcf/gdnMAkkSd2d3s4DYwgJBEh0/+1khaoIlTm1qZYew/SR2HDkLZrMIqEic angH1ssr4Ctxd8cRdojFPUwSs58eByviFHCUaP/aygxiMwrIStz/fo8FYpm4xK0n86GuFpBY suc8M4QtKvHy8T9WCFtRov1pA9RxOhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nL LCQts5C0LGBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGFUHt/y22sF48LnjIUYBDkYl Ht4NNXUhQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0WOF cN6SWn9z1Q3e0rcq0vdP+HHoyJfKzbdnaH5buCxK+qbf4mrxLJ2eQsWHl69uO9k/ebVkY9N5 HbVpZ37cinb5k+V3zyvSz0n7p3GaEePEsKsvPJbOS67XunUu5bPKYUlZs03apeFzzCX4nbrW 9Sj0fzIRETPVuPSzXLNysVm7xiEt2YnzlFiKMxINtZiLihMBPMetsYsCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/jSgcRCvaotM6Io0ZW639eykuOLM Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:57:54 -0000 A few additional comments inline (removing parts of the conversation that w= as already agreed, for brevity) Cheers, Bo > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 3 december 2014 12:50 > To: Bo Burman > Cc: DRAGE, Keith (Keith); avtext@ietf.org > Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy= -03.txt >=20 > Hi Bo, >=20 > Comments inline. This basically all looks good. >=20 > Cheers, > Colin >=20 >=20 >=20 ...snip... > >> Section 2.1.10: > >> - "Each RTP stream defines a unique RTP sequence numbering and timing > >> space" - should be "each SSRC defines", since a change in SSRC require= s a new random offset to sequence number > and timestamp. > > [BoB] True. What about "Each SSRC (even for a single RTP stream, see ab= ove) defines a unique..." to hopefully be even > more clear in connecting that statement back to what applies to an RTP St= ream? >=20 > I don't think that clarifies, especially given the preceding bullet point= says that an RTP stream can have one and only one > SSRC. The key characteristic is that the SSRC has a single sequence numbe= r and timestamp space; this is not true of an > RTP stream, because the SSRC can change. [BoB] OK. I'll just change according to your proposal then. ...snip... > >> Figure 6: > >> - The figure might benefit from having a "synchronisation context" inc= luded? > > [BoB] Maybe, but that is not part of the section where Figure 6 is incl= uded! I also have somewhat of a problem how to > depict it, especially since I don't want the picture to become clobbered.= Do you have any concrete proposal in mind? >=20 > I was going to suggest another box surrounding the RTP Session Audio and = RTP Session Video, but I think your suggestion > below is clearer. [BoB] OK. I can make that change, if you think it is useful. Just a thought: is the Synchronization Context somehow more connected to (i= n this specific picture) Endpoint B, since the interrelation arrows point t= o Media Transports originating from there, and since that Synchronization C= ontext is "created" by Endpoint B? I wonder if it would be useful to have t= he Synchronization Context box partially extend _into_ Endpoint B? Like (pa= rtial picture): | | | | Audio |<--Media Transport--| | | | | | | | | | ^ | | | | | | | | +-----------++--------------|-----++-----------+ | | | | | | || v || | | | | | | || +-----------++----+ | | | | | | || | Synchronization | | | | | | | || | Context | | | | | | | || +-----------++----+ | | | | | | || ^ || | | | | | | +-----------++--------------|-----++-----------+ | | | | | | | | v | | | | | | | | | RTP Session|<--Media Transport--| | | | | At the same time, the Synchronization Context is really _used_ in Endpoint = A, so just extending it into Endpoint B is maybe not clarifying? Better the= n to keep it as a relation "on the wire" as originally suggested? ...snip... > >> Section 2.2.2: ...snip... > >> - Last bullet point - can you give some examples? > > [BoB] I realize that "related" can there be taken to mean either concep= tually related, for example originating from or > targeted for the same endpoint or participant, or (implicitly) by contain= ing RTP streams that are somehow related > (synchronization context, dependency, redundancy, etc), or it can be take= n as a suggestion that there exist some > defined RTP session "handle" allowing for more concrete relation actions,= which is in general not true. > > > > I wonder if the very brief text in this bullet is in fact redundant, su= fficiently discussed in section 3, and could be deleted > here? >=20 > Or keep it, but add a forward reference to Section 3? [BoB] OK. I'll add some brief text along the lines suggested above with for= ward references to Section 3. I think just referencing Section 3 may not be= that helpful. ...snip... > >> Section 3.1.4: > >> - How does an m=3D line relate to the other terms defined here? > > [BoB] I think that is elaborated in the existing term description secti= on 4.2 "Media Description". I can cross reference > that section here. Do you think that is sufficient, or do you want a more= elaborate description here too? >=20 > No, a cross reference to Section 4.2 would be enough. [BoB] OK From nobody Wed Dec 3 09:51:12 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25C11A8AE9; Wed, 3 Dec 2014 09:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi3O9W5eBamd; Wed, 3 Dec 2014 09:50:53 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B5D1A8AF2; Wed, 3 Dec 2014 09:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2447; q=dns/txt; s=iport; t=1417629048; x=1418838648; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=DFXBXqDk9dGC/W54xS5yizI0WPAz/NLp2o0iH6QXRGs=; b=AatHFc9pih596H5EG8+t2310vlYPWxzr4M7ABiBUx32huMuePUVRuPQe NDhjXz4K/ADYfTxaA2zeL7y0akyCovn2ThSo8O2tDueLYpcTS9TsQmAw8 x3XW4NF6n6y20kC6Qm1fw8J/Z4G3ZAHHo5DXe9zsjaNmFJnvsDnj0ZcE8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAJtMf1StJA2K/2dsb2JhbABagwZSxyGGF4EWFgEBAQEBfYQwEz0CgT+IUA3WPgEBAQEGAQEBAQEBAQEBFQSQZoMrgR4FilKJU4Y0gSKFeSWMVoQZHoJ1AQEB X-IronPort-AV: E=Sophos;i="5.07,509,1413244800"; d="scan'208";a="102363874" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-8.cisco.com with ESMTP; 03 Dec 2014 17:50:47 +0000 Received: from [10.24.69.20] ([10.24.69.20]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sB3Hogt6016801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Dec 2014 17:50:45 GMT From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Dec 2014 09:50:41 -0800 Message-Id: <86C3445F-F8D6-4208-8D42-A16B218B146B@cisco.com> To: draft-ietf-avtext-splicing-notification@tools.ietf.org, avtext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/YYj7TnMbtrzbpOvNsIfB3hlpWyI Cc: mmusic Subject: [avtext] SDP directorate review of draft-ietf-avtext-splicing-notification-00 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 17:50:57 -0000 SDP directorate review of draft-ietf-avtext-splicing-notification-00, = Dan Wing, 2-Dec-2014. 1. the SDP in draft-ietf-avtext-splicing-notification is re-using FID = from RFC5888, but is using different semantics. How does a receiver = know if the FID semantics are RFC5888's semantics or are = draft-ietf-avtext-splicing-notification's semantics? Seems we would = benefit from an indication of the semantics in the SDP, perhaps a new = session-level attribute (e.g., "a=3Dsplicing") or perhaps not re-use = a=3Dgroup:FID and instead invent its own grouping for splicing (e.g., = a=3Dgroup:SPLICE). 2. Security Considerations says: In the Secure Real-time Transport Protocol =20 (SRTP)[RFC3711], RTP header extensions are authenticated but not =20 encrypted. A malicious endpoint could choose to set the values in =20= this header extension falsely, so as to falsely claim the splicing =20= time. A malicious endpoint would need the SRTP key to do that, correct? The = I-D should mention that the malicious endpoint needs the SRTP key. =20 Also, auch a malicious endpoint (with possession of the SRTP key) could = also cause splicing of any arbitrary content it wishes, like a Rick = Astley video, which is a different attack that isn't just against the = *time*. I-D should mention that. I don't think either of these are = significant, as the same problem exists without splicing. Nits: =20 1. The SDP in Section 6 has spurious whitespace, for example a space = after "m=3D", which is prohibited by = https://tools.ietf.org/html/rfc4566#page-8 ("Whitespace MUST NOT be used = on either side of the "=3D" sign"). My read of the grouping RFC = (RFC5888) is that it doesn't allow the spurious whitespace after = "a=3Dmid:", either. The SDP in Section 6 is unclear if it is normative = or a non-normative example. 2. Section 3.1 title, "ExtenTion" -> "ExtenSion" 3. Section 4 title, "Reduing" -> "ReduCing" 4. Section 6, OLD: But at a particular point in time, the mixer only selects one stream and output the content from the chosen stream to the downstream receivers. NEW: But at a particular point in time, the mixer only selects one stream and outputs the content from the chosen stream to the downstream .........^ receivers. 5. idnits had a couple of complaints, = https://tools.ietf.org/tools/idnits/webservice -d From nobody Thu Dec 4 04:36:58 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161FF1A026E for ; Thu, 4 Dec 2014 04:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsqR9fdQbfAz for ; Thu, 4 Dec 2014 04:36:53 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263921A0248 for ; Thu, 4 Dec 2014 04:36:53 -0800 (PST) Received: from [130.209.247.112] (port=60881 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XwVeM-0001kq-Au; Thu, 04 Dec 2014 12:36:51 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: Date: Thu, 4 Dec 2014 12:36:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0B48552F-B6DC-4F88-9709-E73F4943834F@csperkins.org> References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89992EDF-E650-4785-AF81-A091D7FDE708@csperkins.org> To: Bo Burman X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/LHSrEjUXE-bUNYQ3qAHktfHdrCs Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 12:36:56 -0000 Hi, A couple of quick comments below. I think we=92re pretty much in = agreement. Cheers, Colin On 3 Dec 2014, at 12:57, Bo Burman wrote: > A few additional comments inline (removing parts of the conversation = that was already agreed, for brevity) >=20 > Cheers, > Bo >=20 >=20 >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: den 3 december 2014 12:50 >> To: Bo Burman >> Cc: DRAGE, Keith (Keith); avtext@ietf.org >> Subject: Re: [avtext] I-D Action: = draft-ietf-avtext-rtp-grouping-taxonomy-03.txt >>=20 >> Hi Bo, >>=20 >> Comments inline. This basically all looks good. >>=20 >> Cheers, >> Colin >>=20 >>=20 >>=20 > ...snip... >>>> Section 2.1.10: >>>> - "Each RTP stream defines a unique RTP sequence numbering and = timing >>>> space" - should be "each SSRC defines", since a change in SSRC = requires a new random offset to sequence number >> and timestamp. >>> [BoB] True. What about "Each SSRC (even for a single RTP stream, see = above) defines a unique..." to hopefully be even >> more clear in connecting that statement back to what applies to an = RTP Stream? >>=20 >> I don't think that clarifies, especially given the preceding bullet = point says that an RTP stream can have one and only one >> SSRC. The key characteristic is that the SSRC has a single sequence = number and timestamp space; this is not true of an >> RTP stream, because the SSRC can change. > [BoB] OK. I'll just change according to your proposal then. >=20 > ...snip... >>>> Figure 6: >>>> - The figure might benefit from having a "synchronisation context" = included? >>> [BoB] Maybe, but that is not part of the section where Figure 6 is = included! I also have somewhat of a problem how to >> depict it, especially since I don't want the picture to become = clobbered. Do you have any concrete proposal in mind? >>=20 >> I was going to suggest another box surrounding the RTP Session Audio = and RTP Session Video, but I think your suggestion >> below is clearer. > [BoB] OK. I can make that change, if you think it is useful. >=20 > Just a thought: is the Synchronization Context somehow more connected = to (in this specific picture) Endpoint B, since the interrelation arrows = point to Media Transports originating from there, and since that = Synchronization Context is "created" by Endpoint B? I wonder if it would = be useful to have the Synchronization Context box partially extend = _into_ Endpoint B? Like (partial picture): >=20 > | | | | Audio |<--Media Transport--| | | | | > | | | | | ^ | | | | | > | | | +-----------++--------------|-----++-----------+ | | | > | | | || v || | | | > | | | || +-----------++----+ | | | > | | | || | Synchronization | | | | > | | | || | Context | | | | > | | | || +-----------++----+ | | | > | | | || ^ || | | | > | | | +-----------++--------------|-----++-----------+ | | | > | | | | | v | | | | | > | | | | RTP Session|<--Media Transport--| | | | | >=20 > At the same time, the Synchronization Context is really _used_ in = Endpoint A, so just extending it into Endpoint B is maybe not = clarifying? Better then to keep it as a relation =93on the wire" as = originally suggested? The synchronisation context is really at the sending side, since that=92s = where the mapping to the NTP-format clock is defined. However, the = diagram shows bi-directional flows, so I=92m not sure that helps. = Leaving it in the middle of the diagram is probably easiest and = clearest. > ...snip... >>>> Section 2.2.2: > ...snip... >>>> - Last bullet point - can you give some examples? >>> [BoB] I realise that =93related=94 can there be taken to mean either = conceptually related, for example originating from or targeted for the = same endpoint or participant, or (implicitly) by containing RTP streams = that are somehow related (synchronization context, dependency, = redundancy, etc), or it can be taken as a suggestion that there exist = some defined RTP session "handle" allowing for more concrete relation = actions, which is in general not true. >>>=20 >>> I wonder if the very brief text in this bullet is in fact redundant, = sufficiently discussed in section 3, and could be deleted here? >>=20 >> Or keep it, but add a forward reference to Section 3? > [BoB] OK. I'll add some brief text along the lines suggested above = with forward references to Section 3. I think just referencing Section 3 = may not be that helpful. Okay, but do keep it brief. I don=92t think much is needed here. > ...snip... >>>> Section 3.1.4: >>>> - How does an m=3D line relate to the other terms defined here? >>> [BoB] I think that is elaborated in the existing term description = section 4.2 "Media Description". I can cross reference >> that section here. Do you think that is sufficient, or do you want a = more elaborate description here too? >>=20 >> No, a cross reference to Section 4.2 would be enough. > [BoB] OK >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Fri Dec 5 01:15:52 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966E1ACE1E; Fri, 5 Dec 2014 01:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qam92lW8CL7v; Fri, 5 Dec 2014 01:15:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34DD1A0075; Fri, 5 Dec 2014 01:15:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMK05226; Fri, 05 Dec 2014 09:15:41 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 5 Dec 2014 09:15:03 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.193]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 5 Dec 2014 17:14:59 +0800 From: "Huangyihong (Rachel)" To: =?utf-8?B?8J+Uk0RhbiBXaW5n?= , "draft-ietf-avtext-splicing-notification@tools.ietf.org" , "avtext@ietf.org" Thread-Topic: SDP directorate review of draft-ietf-avtext-splicing-notification-00 Thread-Index: AQHQDyGz8OOGrsZyvkuiRzIp1VJYHZyAuSHA Date: Fri, 5 Dec 2014 09:14:58 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB8627A5B0@nkgeml501-mbs.china.huawei.com> References: <86C3445F-F8D6-4208-8D42-A16B218B146B@cisco.com> In-Reply-To: <86C3445F-F8D6-4208-8D42-A16B218B146B@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.42.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/of9KbOTNWr-fCqrIa-9f6y-PRes Cc: mmusic Subject: [avtext] =?utf-8?b?562U5aSNOiBTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9m?= =?utf-8?q?_draft-ietf-avtext-splicing-notification-00?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 09:15:46 -0000 SGkgRGFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjYXJlZnVsIHJldmlldy4gVGhlc2UgdHdvIGlz c3VlcyB3aWxsIGJlIGFkZHJlc3NlZCBpbiB0aGUgbmV3IHZlcnNpb24uDQoNCkJSLA0KUmFjaGVs DQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog8J+Uk0RhbiBXaW5nIFttYWls dG86ZHdpbmdAY2lzY28uY29tXSANCuWPkemAgeaXtumXtDogMjAxNOW5tDEy5pyINOaXpSAxOjUx DQrmlLbku7bkuro6IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbkB0b29s cy5pZXRmLm9yZzsgYXZ0ZXh0QGlldGYub3JnDQrmioTpgIE6IG1tdXNpYw0K5Li76aKYOiBTRFAg ZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNh dGlvbi0wMA0KDQpTRFAgZGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0ZXh0LXNw bGljaW5nLW5vdGlmaWNhdGlvbi0wMCwgRGFuIFdpbmcsIDItRGVjLTIwMTQuDQoNCjEuICB0aGUg U0RQIGluIGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbiBpcyByZS11c2lu ZyBGSUQgZnJvbSBSRkM1ODg4LCBidXQgaXMgdXNpbmcgZGlmZmVyZW50IHNlbWFudGljcy4gIEhv dyBkb2VzIGEgcmVjZWl2ZXIga25vdyBpZiB0aGUgRklEIHNlbWFudGljcyBhcmUgUkZDNTg4OCdz IHNlbWFudGljcyBvciBhcmUgZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9u J3Mgc2VtYW50aWNzPyAgU2VlbXMgd2Ugd291bGQgYmVuZWZpdCBmcm9tIGFuIGluZGljYXRpb24g b2YgdGhlIHNlbWFudGljcyBpbiB0aGUgU0RQLCBwZXJoYXBzIGEgbmV3IHNlc3Npb24tbGV2ZWwg YXR0cmlidXRlIChlLmcuLCAiYT1zcGxpY2luZyIpIG9yIHBlcmhhcHMgbm90IHJlLXVzZSBhPWdy b3VwOkZJRCBhbmQgaW5zdGVhZCBpbnZlbnQgaXRzIG93biBncm91cGluZyBmb3Igc3BsaWNpbmcg KGUuZy4sIGE9Z3JvdXA6U1BMSUNFKS4NCg0KMi4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2F5 czoNCg0KICAgSW4gdGhlIFNlY3VyZSBSZWFsLXRpbWUgVHJhbnNwb3J0IFByb3RvY29sICANCiAg IChTUlRQKVtSRkMzNzExXSwgUlRQIGhlYWRlciBleHRlbnNpb25zIGFyZSBhdXRoZW50aWNhdGVk IGJ1dCBub3QgIA0KICAgZW5jcnlwdGVkLiAgQSBtYWxpY2lvdXMgZW5kcG9pbnQgY291bGQgY2hv b3NlIHRvIHNldCB0aGUgdmFsdWVzIGluICANCiAgIHRoaXMgaGVhZGVyIGV4dGVuc2lvbiBmYWxz ZWx5LCBzbyBhcyB0byBmYWxzZWx5IGNsYWltIHRoZSBzcGxpY2luZyAgDQogICB0aW1lLg0KDQpB IG1hbGljaW91cyBlbmRwb2ludCB3b3VsZCBuZWVkIHRoZSBTUlRQIGtleSB0byBkbyB0aGF0LCBj b3JyZWN0PyAgVGhlIEktRCBzaG91bGQgbWVudGlvbiB0aGF0IHRoZSBtYWxpY2lvdXMgZW5kcG9p bnQgbmVlZHMgdGhlIFNSVFAga2V5LiAgDQoNCkFsc28sIGF1Y2ggYSBtYWxpY2lvdXMgZW5kcG9p bnQgKHdpdGggcG9zc2Vzc2lvbiBvZiB0aGUgU1JUUCBrZXkpIGNvdWxkIGFsc28gY2F1c2Ugc3Bs aWNpbmcgb2YgYW55IGFyYml0cmFyeSBjb250ZW50IGl0IHdpc2hlcywgbGlrZSBhIFJpY2sgQXN0 bGV5IHZpZGVvLCB3aGljaCBpcyBhIGRpZmZlcmVudCBhdHRhY2sgdGhhdCBpc24ndCBqdXN0IGFn YWluc3QgdGhlICp0aW1lKi4gIEktRCBzaG91bGQgbWVudGlvbiB0aGF0LiAgSSBkb24ndCB0aGlu ayBlaXRoZXIgb2YgdGhlc2UgYXJlIHNpZ25pZmljYW50LCBhcyB0aGUgc2FtZSBwcm9ibGVtIGV4 aXN0cyB3aXRob3V0IHNwbGljaW5nLg0KDQoNCg0KTml0czogIA0KDQoxLiBUaGUgU0RQIGluIFNl Y3Rpb24gNiBoYXMgc3B1cmlvdXMgd2hpdGVzcGFjZSwgZm9yIGV4YW1wbGUgYSBzcGFjZSBhZnRl ciAibT0iLCB3aGljaCBpcyBwcm9oaWJpdGVkIGJ5IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0NTY2I3BhZ2UtOCAoIldoaXRlc3BhY2UgTVVTVCBOT1QgYmUgdXNlZCBvbiBlaXRoZXIg c2lkZSBvZiB0aGUgIj0iIHNpZ24iKS4gIE15IHJlYWQgb2YgdGhlIGdyb3VwaW5nIFJGQyAoUkZD NTg4OCkgaXMgdGhhdCBpdCBkb2Vzbid0IGFsbG93IHRoZSBzcHVyaW91cyB3aGl0ZXNwYWNlIGFm dGVyICJhPW1pZDoiLCBlaXRoZXIuICBUaGUgU0RQIGluIFNlY3Rpb24gNiBpcyB1bmNsZWFyIGlm IGl0IGlzIG5vcm1hdGl2ZSBvciBhIG5vbi1ub3JtYXRpdmUgZXhhbXBsZS4NCg0KMi4gU2VjdGlv biAzLjEgdGl0bGUsICJFeHRlblRpb24iIC0+ICJFeHRlblNpb24iDQoNCjMuIFNlY3Rpb24gNCB0 aXRsZSwgIlJlZHVpbmciIC0+ICJSZWR1Q2luZyINCg0KNC4gU2VjdGlvbiA2LA0KT0xEOg0KICAg QnV0IGF0DQogICBhIHBhcnRpY3VsYXIgcG9pbnQgaW4gdGltZSwgdGhlIG1peGVyIG9ubHkgc2Vs ZWN0cyBvbmUgc3RyZWFtIGFuZA0KICAgb3V0cHV0IHRoZSBjb250ZW50IGZyb20gdGhlIGNob3Nl biBzdHJlYW0gdG8gdGhlIGRvd25zdHJlYW0NCiAgIHJlY2VpdmVycy4NCk5FVzoNCiAgIEJ1dCBh dA0KICAgYSBwYXJ0aWN1bGFyIHBvaW50IGluIHRpbWUsIHRoZSBtaXhlciBvbmx5IHNlbGVjdHMg b25lIHN0cmVhbSBhbmQNCiAgIG91dHB1dHMgdGhlIGNvbnRlbnQgZnJvbSB0aGUgY2hvc2VuIHN0 cmVhbSB0byB0aGUgZG93bnN0cmVhbSAuLi4uLi4uLi5eDQogICByZWNlaXZlcnMuDQoNCjUuIGlk bml0cyBoYWQgYSBjb3VwbGUgb2YgY29tcGxhaW50cywgaHR0cHM6Ly90b29scy5pZXRmLm9yZy90 b29scy9pZG5pdHMvd2Vic2VydmljZQ0KDQotZA0KDQo= From nobody Fri Dec 5 01:49:17 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AB1ACE0E for ; Fri, 5 Dec 2014 01:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wROy9euD3C4N for ; Fri, 5 Dec 2014 01:49:14 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1E81A897B for ; Fri, 5 Dec 2014 01:49:13 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-25-54817f970a50 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 14.A0.04076.79F71845; Fri, 5 Dec 2014 10:49:11 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.198]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 10:49:10 +0100 From: Bo Burman To: Colin Perkins Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt Thread-Index: AQHQAAM2TU9IvAskwUumiAHVoVNISJxgYKPwgBp7s4CAAY0RQIABZEQAgAAcJdCAAYNTgIABcU6w Date: Fri, 5 Dec 2014 09:49:10 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B27B422@FR712WXCHMBA11.zeu.alcatel-lucent.com> <89992EDF-E650-4785-AF81-A091D7FDE708@csperkins.org> <0B48552F-B6DC-4F88-9709-E73F4943834F@csperkins.org> In-Reply-To: <0B48552F-B6DC-4F88-9709-E73F4943834F@csperkins.org> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje70+sYQg22LJSw+3rvBarH85QlG i6eNZxkdmD1an+1l9Zh2/z6bx5IlP5kCmKO4bFJSczLLUov07RK4Mk4+usZcMF+v4kX/FvYG xvVKXYycHBICJhI7VnxlhLDFJC7cW88GYgsJHGGU+LwvFsJezCjx/2EmiM0moCExf8ddsHoR AVWJHcf/gdnMAkkSd2d3s4DYwgJBEh0/+1khaoIlTm1qZYewoyTefvjFDGKzCKhIPJy0A8zm FfCV6H99GKiGC2hXO7PExo5nTCAJTgFHiZO/V4MVMQrIStz/fo8FYpm4xK0n85kgjhaQWLLn PDOELSrx8vE/VghbUeLq9OVMEPU6Egt2f2KDsLUlli18DbVYUOLkzCcsExjFZiEZOwtJyywk LbOQtCxgZFnFKFqcWlycm25kpJdalJlcXJyfp5eXWrKJERhTB7f8ttrBePC54yFGAQ5GJR7e DfKNIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVHLqYqh ydoszDj5x6m3prZHu1n4UoKkXhzjztPu/fBk0bm+UyJGLl/ytuXsbWx8H3BS+It9ZKVvq1CU e/0C3tUr90wpd5J9OWt5i4eqh6xI2QTL998+POkomuW2SPid/AS5ILOZV8Q/dbAuUAi6w5ro WvOX17H7RLxjyNaNIvrrIg6s28uzRImlOCPRUIu5qDgRAPZOErKKAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/79X4bs-cf9fa1qUoFsz5n0kwHjE Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy-03.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 09:49:16 -0000 "OK" to all of your comments below. Cheers, Bo > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 4 december 2014 13:37 > To: Bo Burman > Cc: DRAGE, Keith (Keith); avtext@ietf.org > Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rtp-grouping-taxonomy= -03.txt >=20 > Hi, >=20 > A couple of quick comments below. I think we're pretty much in agreement. >=20 > Cheers, > Colin >=20 >=20 >=20 > On 3 Dec 2014, at 12:57, Bo Burman wrote: > > A few additional comments inline (removing parts of the conversation > > that was already agreed, for brevity) > > > > Cheers, > > Bo > > > > > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@csperkins.org] > >> Sent: den 3 december 2014 12:50 > >> To: Bo Burman > >> Cc: DRAGE, Keith (Keith); avtext@ietf.org > >> Subject: Re: [avtext] I-D Action: > >> draft-ietf-avtext-rtp-grouping-taxonomy-03.txt > >> > >> Hi Bo, > >> > >> Comments inline. This basically all looks good. > >> > >> Cheers, > >> Colin > >> > >> > >> > > ...snip... > >>>> Section 2.1.10: > >>>> - "Each RTP stream defines a unique RTP sequence numbering and > >>>> timing space" - should be "each SSRC defines", since a change in > >>>> SSRC requires a new random offset to sequence number > >> and timestamp. > >>> [BoB] True. What about "Each SSRC (even for a single RTP stream, see > >>> above) defines a unique..." to hopefully be even > >> more clear in connecting that statement back to what applies to an RTP= Stream? > >> > >> I don't think that clarifies, especially given the preceding bullet > >> point says that an RTP stream can have one and only one SSRC. The key > >> characteristic is that the SSRC has a single sequence number and times= tamp space; this is not true of an RTP stream, > because the SSRC can change. > > [BoB] OK. I'll just change according to your proposal then. > > > > ...snip... > >>>> Figure 6: > >>>> - The figure might benefit from having a "synchronisation context" i= ncluded? > >>> [BoB] Maybe, but that is not part of the section where Figure 6 is > >>> included! I also have somewhat of a problem how to > >> depict it, especially since I don't want the picture to become clobber= ed. Do you have any concrete proposal in mind? > >> > >> I was going to suggest another box surrounding the RTP Session Audio > >> and RTP Session Video, but I think your suggestion below is clearer. > > [BoB] OK. I can make that change, if you think it is useful. > > > > Just a thought: is the Synchronization Context somehow more connected t= o (in this specific picture) Endpoint B, since > the interrelation arrows point to Media Transports originating from there= , and since that Synchronization Context is > "created" by Endpoint B? I wonder if it would be useful to have the Synch= ronization Context box partially extend _into_ > Endpoint B? Like (partial picture): > > > > | | | | Audio |<--Media Transport--| | | | | > > | | | | | ^ | | | | | > > | | | +-----------++--------------|-----++-----------+ | | | > > | | | || v || | | | > > | | | || +-----------++----+ | | | > > | | | || | Synchronization | | | | > > | | | || | Context | | | | > > | | | || +-----------++----+ | | | > > | | | || ^ || | | | > > | | | +-----------++--------------|-----++-----------+ | | | > > | | | | | v | | | | | > > | | | | RTP Session|<--Media Transport--| | | | | > > > > At the same time, the Synchronization Context is really _used_ in Endpo= int A, so just extending it into Endpoint B is > maybe not clarifying? Better then to keep it as a relation "on the wire" = as originally suggested? >=20 > The synchronisation context is really at the sending side, since that's w= here the mapping to the NTP-format clock is > defined. However, the diagram shows bi-directional flows, so I'm not sure= that helps. Leaving it in the middle of the > diagram is probably easiest and clearest. >=20 > > ...snip... > >>>> Section 2.2.2: > > ...snip... > >>>> - Last bullet point - can you give some examples? > >>> [BoB] I realise that "related" can there be taken to mean either conc= eptually related, for example originating from or > targeted for the same endpoint or participant, or (implicitly) by contain= ing RTP streams that are somehow related > (synchronization context, dependency, redundancy, etc), or it can be take= n as a suggestion that there exist some > defined RTP session "handle" allowing for more concrete relation actions,= which is in general not true. > >>> > >>> I wonder if the very brief text in this bullet is in fact redundant, = sufficiently discussed in section 3, and could be > deleted here? > >> > >> Or keep it, but add a forward reference to Section 3? > > [BoB] OK. I'll add some brief text along the lines suggested above with= forward references to Section 3. I think just > referencing Section 3 may not be that helpful. >=20 > Okay, but do keep it brief. I don't think much is needed here. >=20 > > ...snip... > >>>> Section 3.1.4: > >>>> - How does an m=3D line relate to the other terms defined here? > >>> [BoB] I think that is elaborated in the existing term description > >>> section 4.2 "Media Description". I can cross reference > >> that section here. Do you think that is sufficient, or do you want a m= ore elaborate description here too? > >> > >> No, a cross reference to Section 4.2 would be enough. > > [BoB] OK > > >=20 >=20 >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 From nobody Wed Dec 10 02:37:35 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A94A1A1A1E; Wed, 10 Dec 2014 02:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crwpO9IuEtzb; Wed, 10 Dec 2014 02:37:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FF41A1A25; Wed, 10 Dec 2014 02:37:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141210103729.22586.651.idtracker@ietfa.amsl.com> Date: Wed, 10 Dec 2014 02:37:29 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/0cXlIz3pUmhgYcB0pFBeKVRDFc0 Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 10:37: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 Working Group 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-01.txt Pages : 17 Date : 2014-12-10 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: http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Dec 10 02:44:47 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818A1A0169 for ; Wed, 10 Dec 2014 02:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QWCuD5Mb3AF for ; Wed, 10 Dec 2014 02:44:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604A31A0164 for ; Wed, 10 Dec 2014 02:44:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR75839; Wed, 10 Dec 2014 10:44:35 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 10:44:35 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 18:44:29 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt Thread-Index: AQHQFGVfcvT22CJ59ka0fvU8EiMbc5yIog9Q Date: Wed, 10 Dec 2014 10:44:29 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB862979A1@nkgeml501-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.40.194] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/xCt1ZMUFTciH-a0Gc-27fkBkydA Subject: Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 10:44:43 -0000 SGkgYWxsLA0KDQpUaGlzIG5ldyB2ZXJzaW9uIG1hZGUgc29tZSBjaGFuZ2VzIGJhc2VkIHRoZSBj b21tZW50cyByZWNlaXZlZCBmcm9tIHRoZSBtYWlsaW5nIGxpc3QgYW5kIGZyb20gU0RQIGRpcmVj dG9yYXRlIHJldmlldy4gV2UgaG9wZSB3ZSBoYXZlIGFkZHJlc3NlZCB0aGVzZSBjb21tZW50c15e LiBZb3VyIGZ1cnRoZXIgY29tbWVudHMgYW5kIHJldmlld3MgYXJlIGhpZ2hseSBhcHByZWNpYXRl ZC4NCg0KQlIsDQpSYWNoZWwNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGF2dGV4dCBb bWFpbHRvOmF2dGV4dC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZw0Kt6LLzcqxvOQ6IDIwMTTE6jEy1MIxMMjVIDE4OjM3DQrK1bz+yMs6IGktZC1hbm5vdW5j ZUBpZXRmLm9yZw0Ks63LzTogYXZ0ZXh0QGlldGYub3JnDQrW98ziOiBbYXZ0ZXh0XSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDEudHh0DQoNCg0K QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBFeHRlbnNpb25zIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF VEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAgICAgIDogUlRQL1JUQ1AgZXh0ZW5zaW9uIGZvciBS VFAgU3BsaWNpbmcgTm90aWZpY2F0aW9uDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEppbndl aSBYaWENCiAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uaSBFdmVuDQogICAgICAgICAgICAg ICAgICAgICAgICAgIFJhY2hlbCBIdWFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICBMaW5n bGkgRGVuZw0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5v dGlmaWNhdGlvbi0wMS50eHQNCglQYWdlcyAgICAgICAgICAgOiAxNw0KCURhdGUgICAgICAgICAg ICA6IDIwMTQtMTItMTANCg0KQWJzdHJhY3Q6DQogICBDb250ZW50IHNwbGljaW5nIGlzIGEgcHJv Y2VzcyB0aGF0IHJlcGxhY2VzIHRoZSBjb250ZW50IG9mIGEgbWFpbg0KICAgbXVsdGltZWRpYSBz dHJlYW0gd2l0aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQsIGFuZCBkZWxpdmVycyB0aGUNCiAg IHN1YnN0aXR1dGl2ZSBtdWx0aW1lZGlhIGNvbnRlbnQgdG8gdGhlIHJlY2VpdmVycyBmb3IgYSBw ZXJpb2Qgb2YNCiAgIHRpbWUuIFRoZSBzcGxpY2VyIGlzIGRlc2lnbmVkIHRvIGhhbmRsZSBSVFAg c3BsaWNpbmcgYW5kIG5lZWRzIHRvDQogICBrbm93IHdoZW4gdG8gc3RhcnQgYW5kIGVuZCB0aGUg c3BsaWNpbmcuDQoNCiAgIFRoaXMgbWVtbyBkZWZpbmVzIHR3byBSVFAvUlRDUCBleHRlbnNpb25z IHRvIGluZGljYXRlIHRoZSBzcGxpY2luZw0KICAgcmVsYXRlZCBpbmZvcm1hdGlvbiB0byB0aGUg c3BsaWNlcjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdA0KICAgY29udmV5cyB0aGUgaW5m b3JtYXRpb24gaW4tYmFuZCBhbmQgYW4gUlRDUCBwYWNrZXQgdGhhdCBjb252ZXlzIHRoZQ0KICAg aW5mb3JtYXRpb24gb3V0LW9mLWJhbmQuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24vDQoNClRoZXJlJ3MgYWxz byBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9uLTAxDQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNh dGlvbi0wMQ0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmF2dGV4dCBtYWlsaW5nIGxpc3QNCmF2dGV4dEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg== From nobody Wed Dec 10 06:07:33 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB991A9033; Wed, 10 Dec 2014 06:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXixZnh84Zug; Wed, 10 Dec 2014 06:07:29 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6C91A9037; Wed, 10 Dec 2014 06:07:29 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B25DC2CAEEF94; Wed, 10 Dec 2014 14:07:24 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id sBAE7Meh022488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Dec 2014 15:07:27 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 10 Dec 2014 15:07:27 +0100 From: "DRAGE, Keith (Keith)" To: "internet-drafts@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt Thread-Index: AQHQFGW4hgvjKeXQvE2+R66pTmfTjJyI3BEQ Date: Wed, 10 Dec 2014 14:07:25 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B29158B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20141210103729.22586.651.idtracker@ietfa.amsl.com> In-Reply-To: <20141210103729.22586.651.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/toOKT4CsmSsC31SbJCYa3mbf2ns Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Dec 2014 14:07:32 -0000 (As WG cochair) Could the editor indicate whether this is intended to address all reviews m= ade so far, or is it just an intermediate step? Assuming it addresses all, could the reviewers indicate whether their comme= nts have been addressed or not. Regards Keith > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: 10 December 2014 10:37 > To: i-d-announce@ietf.org > Cc: avtext@ietf.org > Subject: [avtext] I-D Action:=20 > draft-ietf-avtext-splicing-notification-01.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport=20 > Extensions Working Group of the IETF. >=20 > Title : RTP/RTCP extension for RTP Splicing=20 > Notification > Authors : Jinwei Xia > Roni Even > Rachel Huang > Lingli Deng > Filename : draft-ietf-avtext-splicing-notification-01.txt > Pages : 17 > Date : 2014-12-10 >=20 > 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. >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-no > tification/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-splicing-no > tification-01 >=20 >=20 > Please note that it may take a couple of minutes from the=20 > time of submission until the htmlized version and diff are=20 > available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > = From nobody Wed Dec 10 18:33:55 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160511A0047; Wed, 10 Dec 2014 18:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUlwSv-GREFT; Wed, 10 Dec 2014 18:33:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAE81A0162; Wed, 10 Dec 2014 18:33:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMS40672; Thu, 11 Dec 2014 02:33:50 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 11 Dec 2014 02:33:48 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 11 Dec 2014 10:33:41 +0800 From: "Huangyihong (Rachel)" To: "DRAGE, Keith (Keith)" , "internet-drafts@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt Thread-Index: AQHQFGVfcvT22CJ59ka0fvU8EiMbc5yIVliAgAFWeaA= Date: Thu, 11 Dec 2014 02:33:41 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86299B21@nkgeml501-mbs.china.huawei.com> References: <20141210103729.22586.651.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8B29158B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B29158B@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.41.177] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/7aDgUOFElkQx4He9FCR5w9QT0EI Cc: "avtext@ietf.org" Subject: Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 02:33:54 -0000 SGkgS2VpdGgsDQoNCkl0J3MgaW50ZW5kZWQgdG8gYWRkcmVzcyBhbGwgdGhlIHJldmlld3MuIFRo YW5rcy4NCg0KQlIsDQpSYWNoZWwNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGF2dGV4 dCBbbWFpbHRvOmF2dGV4dC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERSQUdFLCBLZWl0aCAoS2Vp dGgpDQq3osvNyrG85DogMjAxNMTqMTLUwjEwyNUgMjI6MDcNCsrVvP7IyzogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnDQqzrcvNOiBhdnRleHRAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbYXZ0ZXh0XSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDEudHh0 DQoNCihBcyBXRyBjb2NoYWlyKQ0KDQpDb3VsZCB0aGUgZWRpdG9yIGluZGljYXRlIHdoZXRoZXIg dGhpcyBpcyBpbnRlbmRlZCB0byBhZGRyZXNzIGFsbCByZXZpZXdzIG1hZGUgc28gZmFyLCBvciBp cyBpdCBqdXN0IGFuIGludGVybWVkaWF0ZSBzdGVwPw0KDQpBc3N1bWluZyBpdCBhZGRyZXNzZXMg YWxsLCBjb3VsZCB0aGUgcmV2aWV3ZXJzIGluZGljYXRlIHdoZXRoZXIgdGhlaXIgY29tbWVudHMg aGF2ZSBiZWVuIGFkZHJlc3NlZCBvciBub3QuDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhdnRleHQgW21haWx0bzphdnRleHQtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcN Cj4gU2VudDogMTAgRGVjZW1iZXIgMjAxNCAxMDozNw0KPiBUbzogaS1kLWFubm91bmNlQGlldGYu b3JnDQo+IENjOiBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogW2F2dGV4dF0gSS1EIEFjdGlv bjogDQo+IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wMS50eHQNCj4g DQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgDQo+IGRpcmVjdG9yaWVzLg0KPiAgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNwb3J0IEV4dGVuc2lvbnMgDQo+IFdvcmtp bmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFJU UC9SVENQIGV4dGVuc2lvbiBmb3IgUlRQIFNwbGljaW5nIA0KPiBOb3RpZmljYXRpb24NCj4gICAg ICAgICBBdXRob3JzICAgICAgICAgOiBKaW53ZWkgWGlhDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgUm9uaSBFdmVuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgUmFjaGVsIEh1YW5n DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgTGluZ2xpIERlbmcNCj4gCUZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wMS50eHQNCj4g CVBhZ2VzICAgICAgICAgICA6IDE3DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE0LTEyLTEwDQo+ IA0KPiBBYnN0cmFjdDoNCj4gICAgQ29udGVudCBzcGxpY2luZyBpcyBhIHByb2Nlc3MgdGhhdCBy ZXBsYWNlcyB0aGUgY29udGVudCBvZiBhIG1haW4NCj4gICAgbXVsdGltZWRpYSBzdHJlYW0gd2l0 aCBvdGhlciBtdWx0aW1lZGlhIGNvbnRlbnQsIGFuZCBkZWxpdmVycyB0aGUNCj4gICAgc3Vic3Rp dHV0aXZlIG11bHRpbWVkaWEgY29udGVudCB0byB0aGUgcmVjZWl2ZXJzIGZvciBhIHBlcmlvZCBv Zg0KPiAgICB0aW1lLiBUaGUgc3BsaWNlciBpcyBkZXNpZ25lZCB0byBoYW5kbGUgUlRQIHNwbGlj aW5nIGFuZCBuZWVkcyB0bw0KPiAgICBrbm93IHdoZW4gdG8gc3RhcnQgYW5kIGVuZCB0aGUgc3Bs aWNpbmcuDQo+IA0KPiAgICBUaGlzIG1lbW8gZGVmaW5lcyB0d28gUlRQL1JUQ1AgZXh0ZW5zaW9u cyB0byBpbmRpY2F0ZSB0aGUgc3BsaWNpbmcNCj4gICAgcmVsYXRlZCBpbmZvcm1hdGlvbiB0byB0 aGUgc3BsaWNlcjogYW4gUlRQIGhlYWRlciBleHRlbnNpb24gdGhhdA0KPiAgICBjb252ZXlzIHRo ZSBpbmZvcm1hdGlvbiBpbi1iYW5kIGFuZCBhbiBSVENQIHBhY2tldCB0aGF0IGNvbnZleXMgdGhl DQo+ICAgIGluZm9ybWF0aW9uIG91dC1vZi1iYW5kLg0KPiANCj4gDQo+IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ubw0KPiB0aWZpY2F0 aW9uLw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5n LW5vdGlmaWNhdGlvbi0wMQ0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWF2dGV4dC1zcGxpY2luZy1ubw0KPiB0aWZpY2F0aW9uLTAxDQo+IA0KPiANCj4gUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2YgDQo+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCANCj4gdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBhdnRleHQgbWFpbGluZyBsaXN0DQo+IGF2dGV4dEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dGV4dA0K PiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQphdnRl eHQgbWFpbGluZyBsaXN0DQphdnRleHRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXZ0ZXh0DQo= From nobody Mon Dec 15 10:50:47 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16331A873F; Mon, 15 Dec 2014 10:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNZGMKlX8293; Mon, 15 Dec 2014 10:25:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B18DA1A8725; Mon, 15 Dec 2014 10:25:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: xiajinwei@huawei.com, ron.even.tlv@gmail.com, rachel.huang@huawei.com, denglingli@chinamobile.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141215182527.6369.52661.idtracker@ietfa.amsl.com> Date: Mon, 15 Dec 2014 10:25:27 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/NzjRd8lHlaicWf_MLM7PW_1eRik X-Mailman-Approved-At: Mon, 15 Dec 2014 10:50:45 -0800 Cc: jonathan@vidyo.com, avtext@ietf.org, ipr-announce@ietf.org Subject: [avtext] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-avtext-splicing-notification-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:25:30 -0000 Dear Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli: An IPR disclosure that pertains to your Internet-Draft entitled "RTP/RTCP extension for RTP Splicing Notification" (draft-ietf-avtext-splicing- notification) was submitted to the IETF Secretariat on 2014-12-15 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2500/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-avtext- splicing-notification-01.""); The IETF Secretariat From nobody Mon Dec 15 10:59:08 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D71A8759 for ; Mon, 15 Dec 2014 10:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAVIOO_bSPhE for ; Mon, 15 Dec 2014 10:59:06 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8651A86E0 for ; Mon, 15 Dec 2014 10:59:05 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id E2767D6451319 for ; Mon, 15 Dec 2014 18:59:00 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sBFIx304028591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 15 Dec 2014 19:59:03 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 15 Dec 2014 19:59:03 +0100 From: "DRAGE, Keith (Keith)" To: "avtext@ietf.org" Thread-Topic: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-avtext-splicing-notification-01 Thread-Index: AQHQGJSFA6SCqoUYyUCGndZHH6mKPpyRAA1g Date: Mon, 15 Dec 2014 18:59:03 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B2954C4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/m_Sn7P_WBTiTkizLFenwhFT4x3I Subject: [avtext] FW: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-avtext-splicing-notification-01 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 18:59:07 -0000 (As WG cochair) Can I ask the authors of this draft whether this is the first indication we= have had of IPR in this document. My look back through the archives has identified no previous indication fro= m the authors, most of who work for the same company. Regards Keith =20 -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org]=20 Sent: 15 December 2014 18:25 To: xiajinwei@huawei.com; ron.even.tlv@gmail.com; rachel.huang@huawei.com; = denglingli@chinamobile.com Cc: rlb@ipv.sx; alissa@cooperw.in; DRAGE, Keith (Keith); jonathan@vidyo.com= ; avtext@ietf.org; ipr-announce@ietf.org Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR= related to draft-ietf-avtext-splicing-notification-01 Dear Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli: An IPR disclosure that pertains to your Internet-Draft entitled "RTP/RTCP = extension for RTP Splicing Notification" (draft-ietf-avtext-splicing- notification) was submitted to the IETF Secretariat on 2014-12-15 and has b= een posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2500/). The title of the IPR disclosure i= s "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-= avtext- splicing-notification-01.""); The IETF Secretariat From nobody Mon Dec 15 22:54:34 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE01ACD2B for ; Mon, 15 Dec 2014 22:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.078 X-Spam-Level: ** X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agM0mUxGBln5 for ; Mon, 15 Dec 2014 22:54:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2FC1A19F6 for ; Mon, 15 Dec 2014 22:54:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQC87892; Tue, 16 Dec 2014 06:54:29 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 16 Dec 2014 06:54:27 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.169]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Tue, 16 Dec 2014 14:54:19 +0800 From: Xiajinwei To: "DRAGE, Keith (Keith)" , "avtext@ietf.org" Thread-Topic: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-avtext-splicing-notification-01 Thread-Index: AQHQGJSFfcxIVC/GbUyRq98dB7z0uJyRAA1ggAC+6DA= Date: Tue, 16 Dec 2014 06:54:18 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B2954C4@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B2954C4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.164] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/8mMcBvPczjJJCwUmc6yyIoMx5dE Subject: [avtext] =?gb2312?b?tPC4tDogSVBSIERpc2Nsb3N1cmU6IEh1YXdlaSBUZWNo?= =?gb2312?b?bm9sb2dpZXMgQ28uLCBMdGQncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0?= =?gb2312?b?ZWQgdG8gZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9u?= =?gb2312?b?LTAx?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 06:54:33 -0000 SGkgQ2hhaXIsDQoNClRoaXMgaXMgaW5kZWVkIHRoZSBmaXJzdCB0aW1lIHRvIGluZGljYXRlIHRo ZSBJUFIuIFRoaXMgZHJhZnQgaXMgYmFzZWQgb24gdGhlIHJlcXVpcmVtZW50cyBmcm9tIG9uZSBD aGluYSBJUFRWIG9wZXJhdG9yLCBzbyB3ZSBkbyBpdC4gDQoNCkJ1dCB3ZSAodGhlIGF1dGhvcnMp IGhhdmUgbm8gaWRlYSB3aGljaCBkZXBhcnRtZW50IG9mIEh1YXdlaSB0aGUgSVBSIGNvbWVzIGZy b20sIG90aGVyd2lzZSwgd2Ugd2lsbCBpbmRpY2F0ZSBpdCBhcyBlYXJseSBhcyBwb3NzaWJsZS4N Cg0KQlINCkppbndlaQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IGF2dGV4dCBb bWFpbHRvOmF2dGV4dC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIERSQUdFLCBLZWl0aCAoS2VpdGgp DQo+ILeiy83KsbzkOiAyMDE0xOoxMtTCMTbI1SAyOjU5DQo+IMrVvP7IyzogYXZ0ZXh0QGlldGYu b3JnDQo+INb3zOI6IFthdnRleHRdIEZXOiBJUFIgRGlzY2xvc3VyZTogSHVhd2VpIFRlY2hub2xv Z2llcyBDby4sIEx0ZCdzIFN0YXRlbWVudA0KPiBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1p ZXRmLWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDENCj4gDQo+IChBcyBXRyBjb2NoYWly KQ0KPiANCj4gQ2FuIEkgYXNrIHRoZSBhdXRob3JzIG9mIHRoaXMgZHJhZnQgd2hldGhlciB0aGlz IGlzIHRoZSBmaXJzdCBpbmRpY2F0aW9uIHdlIGhhdmUNCj4gaGFkIG9mIElQUiBpbiB0aGlzIGRv Y3VtZW50Lg0KPiANCj4gTXkgbG9vayBiYWNrIHRocm91Z2ggdGhlIGFyY2hpdmVzIGhhcyBpZGVu dGlmaWVkIG5vIHByZXZpb3VzIGluZGljYXRpb24gZnJvbQ0KPiB0aGUgYXV0aG9ycywgbW9zdCBv ZiB3aG8gd29yayBmb3IgdGhlIHNhbWUgY29tcGFueS4NCj4gDQo+IFJlZ2FyZHMNCj4gDQo+IEtl aXRoDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElF VEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLWlwckBpZXRmLm9yZ10NCj4gU2VudDogMTUgRGVj ZW1iZXIgMjAxNCAxODoyNQ0KPiBUbzogeGlhamlud2VpQGh1YXdlaS5jb207IHJvbi5ldmVuLnRs dkBnbWFpbC5jb207DQo+IHJhY2hlbC5odWFuZ0BodWF3ZWkuY29tOyBkZW5nbGluZ2xpQGNoaW5h bW9iaWxlLmNvbQ0KPiBDYzogcmxiQGlwdi5zeDsgYWxpc3NhQGNvb3BlcncuaW47IERSQUdFLCBL ZWl0aCAoS2VpdGgpOyBqb25hdGhhbkB2aWR5by5jb207DQo+IGF2dGV4dEBpZXRmLm9yZzsgaXBy LWFubm91bmNlQGlldGYub3JnDQo+IFN1YmplY3Q6IElQUiBEaXNjbG9zdXJlOiBIdWF3ZWkgVGVj aG5vbG9naWVzIENvLiwgTHRkJ3MgU3RhdGVtZW50IGFib3V0IElQUg0KPiByZWxhdGVkIHRvIGRy YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wMQ0KPiANCj4gDQo+IERlYXIg Smlud2VpIFhpYSwgUm9uaSBFdmVuLCBSYWNoZWwgSHVhbmcsIERlbmcgTGluZ2xpOg0KPiANCj4g IEFuIElQUiBkaXNjbG9zdXJlIHRoYXQgcGVydGFpbnMgdG8geW91ciBJbnRlcm5ldC1EcmFmdCBl bnRpdGxlZCAiUlRQL1JUQ1ANCj4gZXh0ZW5zaW9uIGZvciBSVFAgU3BsaWNpbmcgTm90aWZpY2F0 aW9uIiAoZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctDQo+IG5vdGlmaWNhdGlvbikgd2FzIHN1 Ym1pdHRlZCB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBvbiAyMDE0LTEyLTE1IGFuZCBoYXMgYmVl bg0KPiBwb3N0ZWQgb24gdGhlICJJRVRGIFBhZ2Ugb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJp Z2h0cyBEaXNjbG9zdXJlcyINCj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzI1 MDAvKS4gVGhlIHRpdGxlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSBpcw0KPiAiSHVhd2VpIFRlY2hu b2xvZ2llcyBDby4sTHRkJ3MgU3RhdGVtZW50IGFib3V0IElQUiByZWxhdGVkIHRvDQo+IGRyYWZ0 LWlldGYtYXZ0ZXh0LSBzcGxpY2luZy1ub3RpZmljYXRpb24tMDEuIiIpOw0KPiANCj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGF2dGV4dCBtYWlsaW5nIGxpc3QNCj4gYXZ0ZXh0QGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0ZXh0DQo= From nobody Tue Dec 16 05:38:21 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3D1A1B0C for ; Tue, 16 Dec 2014 05:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILUTd4qOna-c for ; Tue, 16 Dec 2014 05:38:17 -0800 (PST) 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 0C2C11A1AB3 for ; Tue, 16 Dec 2014 05:38:16 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-29-549035c7baae Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.FB.04231.7C530945; Tue, 16 Dec 2014 14:38:15 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.7]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Tue, 16 Dec 2014 14:38:14 +0100 From: Jonatan Samuelsson To: Muhammed Coban , Stephan Wenger , "avtext@ietf.org" Thread-Topic: New Version Notification for draft-samuelsson-avtext-rpvi-00.txt Thread-Index: AQHQGEYqTJ8tmfew1k2upDBqpV/W25ySLPGw Date: Tue, 16 Dec 2014 13:38:14 +0000 Message-ID: <634D3B5D82E3214DA9B6A36D5F50DB23362AF6@ESESSMB109.ericsson.se> References: <20141215090437.29661.70997.idtracker@ietfa.amsl.com> In-Reply-To: <20141215090437.29661.70997.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUyM+Jvje5x0wkhBnf2SFh8vHeD1WJq42om i+uNm9gdmD2WLPnJ5LFo6jNGj8Xr3zMGMEdx2aSk5mSWpRbp2yVwZWzt72QseCRfMe1/L2MD 4w+5LkZODgkBE4meGVPZIWwxiQv31rN1MXJxCAkcYZRYs+cGO4SziFHiy8ErLF2MHBxsAlYS 319EgDSICJRKTLt8hQnEFhbwldiw5xMjRDxAYsPFN1C2kcSZ/oVsIDaLgKpEd+dvZhCbV8Bb onPeFFYQW0jAUaJ38XEwm1PASWLPtMdgNYwCshL3v99jAbGZBcQlbj2ZzwRxqIDEkj3nmSFs UYmXj/+xQthKEmsPbwc7k1lAU2L9Ln2IVkWJKd0P2SHWCkqcnPmEZQKj6CwkU2chdMxC0jEL SccCRpZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIFxc3DLb90djKtfOx5iFOBgVOLhNVjQ HyLEmlhWXJl7iFGag0VJnHfRuXnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhi9zE6ZxMYX V8/lX9azV7CJybJ/e7PF9QKp5U1rE5d+WssX+D/p0HuRzhMOzPNV9WXXHfiwp2GVsob1cQf9 1qUN3N2SVn+niGyxjPhsndgTbXG3/3DolEdacTtNpfLEsrbWTuc55aKQGRXu/3K3NvsDcStJ LS3jz1G/4iZXXPF1zIh9KeEdocRSnJFoqMVcVJwIAIjQG3R8AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/8KU_I3yxs4f8WOKQYvciV4r2-vw Subject: Re: [avtext] New Version Notification for draft-samuelsson-avtext-rpvi-00.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:38:19 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuIFRoZSBkcmFmdCBkZXNjcmliZXMgYSBuZXcgZmVlZGJhY2sgbWVzc2FnZSAoUlBW SSkgaW50ZW5kZWQgdG8gYXVnbWVudCB0aGUgZmVlZGJhY2sgbWVzc2FnZXMgZGVmaW5lZCBpbiBb UkZDNDU4NV0sIFtSRkM1MTA0XSBhbmQgW1JGQzY2NDJdLg0KDQpUaGUgUlBWSSBmZWVkYmFjayBt ZXNzYWdlIGVuYWJsZXMgdGhlIGZvbGxvd2luZyBmZWF0dXJlczoNCiAtIEluZGljYXRpb24gb2Yg bXVsdGlwbGUgcmVmZXJlbmNlIHBpY3R1cmVzIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHJlZmVyZW5j ZQ0KIC0gSW5kaWNhdGlvbiBvZiBsb3NzIG9mIGEgc3BlY2lmaWMgcGljdHVyZQ0KIC0gSW5kaWNh dGlvbiBvZiBpbmNvcnJlY3QgRGVjb2RlZCBQaWN0dXJlIEhhc2ggdmFsdWUNCiAtIFBvc3NpYmls aXR5IHRvIGluY2x1ZGUgRGVjb2RlZCBQaWN0dXJlIEhhc2ggdmFsdWUgaW4gdGhlIGZlZWRiYWNr IG1lc3NhZ2UgKGluIG9yZGVyIGZvciB0aGUgbWVkaWEgc2VuZGVyIHRvIHZlcmlmeSB0aGF0IGEg c3BlY2lmaWMgcGljdHVyZSBoYXMgYmVlbiBjb3JyZWN0bHkgZGVjb2RlZCkNCg0KQWxsIG9mIHRo ZXNlIGZlYXR1cmVzIHdlcmUgZGlzY3Vzc2VkIGR1cmluZyB0aGUgZHJhZnRpbmcgb2YgdGhlIFJU UCBwYXlsb2FkIGZvcm1hdCBmb3IgSC4yNjUvSEVWQy4gSG93ZXZlciwgYXQgdGhhdCB0aW1lIGl0 IHdhcyBkZWNpZGVkIHRvIGRlZmluZSBhIGdlbmVyaWMgc2NoZW1lIChub3QgbGltaXRlZCB0byBI RVZDKSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50Lg0KDQpZb3VyIGZlZWRiYWNrIG9uIHRoZSBkcmFm dCBpcyBoaWdobHkgYXBwcmVjaWF0ZWQuDQoNCkJlc3QgUmVnYXJkcyBKb25hdGFuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogZGVuIDE1IGRlY2VtYmVyIDIw MTQgMTA6MDUNClRvOiBNdWhhbW1lZCBDb2JhbjsgU3RlcGhhbiBXZW5nZXI7IE11aGFtbWVkIENv YmFuOyBKb25hdGFuIFNhbXVlbHNzb247IFN0ZXBoYW4gV2VuZ2VyOyBKb25hdGFuIFNhbXVlbHNz b24NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc2FtdWVsc3Nv bi1hdnRleHQtcnB2aS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtc2Ft dWVsc3Nvbi1hdnRleHQtcnB2aS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgSm9uYXRhbiBTYW11ZWxzc29uIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KTmFtZToJCWRyYWZ0LXNhbXVlbHNzb24tYXZ0ZXh0LXJwdmkNClJldmlzaW9uOgkwMA0K VGl0bGU6CQlSZWZlcmVuY2UgUGljdHVyZSBWZXJpZmljYXRpb24gSW5mb3JtYXRpb24gaW4gdGhl IFJUUCBBdWRpby1WaXN1YWwgUHJvZmlsZSB3aXRoIEZlZWRiYWNrIChBVlBGKQ0KRG9jdW1lbnQg ZGF0ZToJMjAxNC0xMi0xNQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJ MTENClVSTDogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1zYW11ZWxzc29uLWF2dGV4dC1ycHZpLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhbXVlbHNzb24tYXZ0ZXh0LXJwdmkv DQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FtdWVs c3Nvbi1hdnRleHQtcnB2aS0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVj aWZpZXMgYW4gZXh0ZW5zaW9uIHRvIHRoZSBmZWVkYmFjayBtZXNzYWdlcyBkZWZpbmVkDQogICBp biB0aGUgQXVkaW8tVmlzdWFsIFByb2ZpbGUgd2l0aCBGZWVkYmFjayAoQVZQRikuIFRoZSBuZXcg UmVmZXJlbmNlDQogICBQaWN0dXJlIFZlcmlmaWNhdGlvbiBJbmZvcm1hdGlvbiAoUlBWSSkgZmVl ZGJhY2sgbWVzc2FnZSBjb252ZXlzDQogICBpbmZvcm1hdGlvbiBhYm91dCBhdmFpbGFibGUgcmVm ZXJlbmNlIHBpY3R1cmVzIGluIHRoZSBkZWNvZGVkIHBpY3R1cmUNCiAgIGJ1ZmZlciBvZiBhIHZp ZGVvIGRlY29kZXIgaW4gdGhlIHJlY2VpdmVyIG9mIGFuIFJUUCB2aWRlbyBzdHJlYW0uDQoNCiAg IEJ5IGluY2x1ZGluZyBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIERlY29kZWQgUGljdHVyZSBIYXNo IChEUEgpDQogICB2YWx1ZXMsIG1lZGlhIHNlbmRlcnMgYW5kIG1lZGlhIHJlY2VpdmVycyBjYW4g dmVyaWZ5IHRoYXQgcmVmZXJlbmNlDQogICBwaWN0dXJlcyB1c2VkIGZvciBwcmVkaWN0aW9uIGJ5 IHRoZSB2aWRlbyBlbmNvZGVyIGFuZCB0aGUgdmlkZW8NCiAgIGRlY29kZXIgYXJlIGFsaWduZWQu IEl0IGlzIGFsc28gcG9zc2libGUgdG8gdXNlIHRoZSBSUFZJIGZlZWRiYWNrDQogICBtZXNzYWdl IHRvIGluZGljYXRlIHRoYXQgYSBzcGVjaWZpYyByZWZlcmVuY2UgcGljdHVyZSBoYXMgaW5jb3Jy ZWN0DQogICBzYW1wbGUgdmFsdWVzIChpLmUuIGEgbWlzbWF0Y2ggaW4gdGhlIERQSCB2YWx1ZSBi ZXR3ZWVuIGVuY29kZXIgYW5kDQogICBkZWNvZGVyKSBvciB0aGF0IGEgc3BlY2lmaWMgcmVmZXJl bmNlIHBpY3R1cmUgaGFzIGJlZW4gbG9zdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9t IHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From nobody Thu Dec 18 02:04:30 2014 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD461A8790 for ; Thu, 18 Dec 2014 02:04:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv16MUfYElgw for ; Thu, 18 Dec 2014 02:04:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CBE1A8784 for ; Thu, 18 Dec 2014 02:04:23 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-d2-5492a6a58725 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 25.5C.04076.5A6A2945; Thu, 18 Dec 2014 11:04:21 +0100 (CET) Received: from ESESSMB105.ericsson.se ([169.254.5.190]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 11:04:21 +0100 From: Bo Burman To: Stephan Wenger , Colin Perkins Thread-Topic: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft Thread-Index: AdANcy1ghIExnfAhTOSOExg/j09GzQAo1OeAAAt56oADGTfHIA== Date: Thu, 18 Dec 2014 10:04:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_BBE9739C2C302046BD34B42713A1E2A22E421BB3ESESSMB105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM+Jvje7SZZNCDI61Glt8vHeD1WL5yxOM Fvd7NjNazO9qZbW43riJ3YHVY9r9+2weS5b8ZPJYvP49o8eXy5/ZAliiuGxSUnMyy1KL9O0S uDJ+HbnJXDBxEmPFg69X2BoYrzcydjFyckgImEgsenWaDcIWk7hwbz2QzcUhJHCEUeLj0wPs EM4SRom2h69YQarYBDQk5u+4C9YtIuAusaC5kQWkiFngL6PEhlsXgBIcHMICsRKXtiZA1MRJ HNv1gQnCdpK4++0mM0gJi4CqxKN1ziBhXgFfif5JHcwQu5YzSlxfM50dJMEpoCvxeM0yFhCb UUBW4v73e2A2s4C4xK0n85kgrhaQWLLnPDOELSrx8vE/VghbUeLq9OVMEPX5En/m7WSFWCYo cXLmE5YJjKKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg3 3chIL7UoM7m4OD9PLy+1ZBMjME4PbvlttYPx4HPHQ4wCHIxKPLwGzpNChFgTy4orcw8xSnOw KInzLjw3L1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY42tx7Sm4uji3AOKB0UOnUoW+1lh m/WpIGjPj5cvOzlEythjd6al57A+E7SIXur0Olij8zgDe4GZk/vOQw9PBX3fdeHQ/6ds+Ukz q/e3HxC8+fHWvxDrops19+VMb3HyO06s0WKuulQxp3ZxuqC0aNrRsNaDH1xtVE6WPWt69DR3 RdsUnzkXlFiKMxINtZiLihMBW0Qg2rQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/avtext/j2kTCv0UPa3MwuGux3nYUue7sKM Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" , "avtext@ietf.org" , "draft-ietf-avtcore-rtp-topologies-update@tools.ietf.org" Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP grouping taxonomy draft X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 10:04:29 -0000 --_000_BBE9739C2C302046BD34B42713A1E2A22E421BB3ESESSMB105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since there was no objections to my proposal to change to "Endpoint", I wil= l make this change in the next version of the draft. Since the WGLC ended December 5th, I will shortly submit an updated version= , addressing the comments received during the WGLC. /Bo From: Stephan Wenger [mailto:stewe@stewe.org] Sent: den 2 december 2014 17:27 To: Colin Perkins; Bo Burman Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org; avtext@ietf.org; draft-ietf= -avtcore-rtp-topologies-update@tools.ietf.org Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP groupin= g taxonomy draft Same re topologies-update. (We actually changed it to "End Point" for alignment with the taxonomy draf= t in the first place.) Stephan From: Colin Perkins > Date: Tuesday, December 2, 2014 at 02:58 To: Bo Burman > Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" >, "avtext@ietf.org" >, "draft-ietf-avtcor= e-rtp-topologies-update@tools.ietf.org" > Subject: Re: [avtext] Resolving editor's note on "End Point" in RTP groupin= g taxonomy draft No objection on my part. I'll change the rtcweb-rtp-usage draft to match th= e agreed term - let me know. Colin On 2 Dec 2014, at 07:58, Bo Burman > wrote: Hi, There's an editor's note in draft-ietf-avtext-rtp-grouping-taxonomy-03 sect= ion 2.2.1 pondering whether the current "End Point" or the single-word "End= point" should be used as term. This editor's note needs to be resolved. I would like see this changed to the single-word term "Endpoint", since I b= elieve it is a more used term in RTP context (based on having searched thro= ugh various RTP-related documents), and I also believe the semantics in thi= s draft aligns well with the use of the term "endpoint" in those documents. To get a sense of the possible impact of this change to documents that refe= rences this draft, I have searched the IETF database for documents that bot= h references this draft and uses any form of "end point", "end-point" or "e= ndpoint". I can find only two documents that references the taxonomy draft,= uses any form of the term, and that are too far progressed to change; * draft-ietf-dart-dscp-rtp, uses the term "endpoint" (in RFC Ed Queue) * draft-ietf-payload-rtp-h265, uses "endpoint" (publication requested) I can only find two less progressed documents (omitting any pre-WG Last Cal= l documents) that references the taxonomy draft and that uses any form of t= he term; * draft-ietf-rtcweb-rtp-usage, uses "End-point" (WG consensus, waiting for writ= e-up) * draft-ietf-avtcore-rtp-topologies-update, uses "End Point" (in W= G Last Call) So, the only documents that are too far progressed to change both use the s= ingle-word form "endpoint", which is thus fully in line with my suggested c= hange. If you oppose this change for some reason, please speak up. If there are no= major objections, I will make this change in the next version. Cheers, Bo --_000_BBE9739C2C302046BD34B42713A1E2A22E421BB3ESESSMB105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since there was no obj= ections to my proposal to change to “Endpoint”, I will make thi= s change in the next version of the draft.

Since the WGLC ended D= ecember 5th, I will shortly submit an updated version, addressin= g the comments received during the WGLC.

 

/Bo<= /p>

 

From: Stephan = Wenger [mailto:stewe@stewe.org]
Sent: den 2 december 2014 17:27
To: Colin Perkins; Bo Burman
Cc: draft-ietf-rtcweb-rtp-usage@tools.ietf.org; avtext@ietf.org; dra= ft-ietf-avtcore-rtp-topologies-update@tools.ietf.org
Subject: Re: [avtext] Resolving editor's note on "End Point&quo= t; in RTP grouping taxonomy draft

 

Same re= topologies-update.

(We act= ually changed it to "End Point” for alignment with the taxonomy = draft in the first place.)

Stephan=

&n= bsp;

From: Colin Perkins <csp@csperkins.org>
Date: Tuesday, December 2, 2014 at 02:58
To: Bo Burman <bo.burma= n@ericsson.com>
Cc: "draft-ietf-rtcweb-rtp-usage@tools.ietf.org" <draft-ietf-rtcweb-rtp-usage= @tools.ietf.org>, "avtext@ie= tf.org" <avtext@ietf.org>, "draf= t-ietf-avtcore-rtp-topologies-update@tools.ietf.org" <draft-i= etf-avtcore-rtp-topologies-update@tools.ietf.org>
Subject: Re: [avtext] Resolving editor's note on "End Point&quo= t; in RTP grouping taxonomy draft

&n= bsp;

No obje= ction on my part. I’ll change the rtcweb-rtp-usage draft to match the= agreed term - let me know.

&n= bsp;

Colin

&n= bsp;

&n= bsp;

On 2 De= c 2014, at 07:58, Bo Burman <b= o.burman@ericsson.com> wrote:

Hi,

 

There’s an editor&= #8217;s note in draft-ietf-avtext-rtp-grouping-taxonomy-03 section 2.2.1 pondering whet= her the current “End Point” or the single-word “Endpoint&= #8221; should be used as term. This editor’s note needs to be resolve= d.

 =

I would like see this ch= anged to the single-word term “Endpoint”, since I believe it is= a more used term in RTP context (based on having searched through various = RTP-related documents), and I also believe the semantics in this draft aligns well with the use of the term “endpoint” = in those documents.

 =

To get a sense of the po= ssible impact of this change to documents that references this draft, I hav= e searched the IETF database for documents that both references this draft = and uses any form of “end point”, “end-point” or “endpoint”. I can find only two documents that references t= he taxonomy draft, uses any form of the term, and that are too far progress= ed to change;

·         draft-ietf-dart-dscp= -rtp, uses the term “endpoint” (in RFC Ed Queue)=

·         draft-ietf-payloa= d-rtp-h265, uses “endpoint” (publication requested)

 =

I can only find two less= progressed documents (omitting any pre-WG Last Call documents) that refere= nces the taxonomy draft and that uses any form of the term;

·         draft-ietf-rtcweb= -rtp-usage, uses ”End-point” (WG consensus, waiting for wri= te-up)

·         draf= t-ietf-avtcore-rtp-topologies-update, uses “End Point” (in = WG Last Call)

 =

So, the only documents t= hat are too far progressed to change both use the single-word form “e= ndpoint”, which is thus fully in line with my suggested change.<= /o:p>

 =

If you oppose this chang= e for some reason, please speak up. If there are no major objections, I wil= l make this change in the next version.

 =

Cheers,

Bo

&n= bsp;

--_000_BBE9739C2C302046BD34B42713A1E2A22E421BB3ESESSMB105erics_--