From christer.holmberg@ericsson.com Tue Oct 1 01:09:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AF121F9C47 for ; Tue, 1 Oct 2013 01:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=-1.545, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SgCcsasKw8e for ; Tue, 1 Oct 2013 01:09:03 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 037B121F9C3A for ; Tue, 1 Oct 2013 01:09:00 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-ba-524a831b0efd Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A3.AD.25272.B138A425; Tue, 1 Oct 2013 10:08:59 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 10:08:59 +0200 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJwAJNF4AAB11LgAAgl6UgAAQPZIw Date: Tue, 1 Oct 2013 08:08:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> In-Reply-To: <524A2EFF.9040908@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvra50s1eQwZOHehZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mo4sk6i4JVbxd/T19gbGBdYdDFyckgImEgc XP2YHcIWk7hwbz1bFyMXh5DAUUaJM9dmMkM4ixklTm6ZC+RwcLAJWEh0/9MGMUWAmuef1QTp ZRZQlvjasIkJxBYWUJB4/2InM4gtIqAo8ffbDnaQMSICTYwSWx43sIIkWARUJJa/WMsIYvMK +Eo8OreLCWLXBRaJle+Pg3VzCuhI7P3yH+w6RqDrvp9awwSxTVzi1pP5TBBXC0gs2XOeGcIW lXj5+B8rhK0o8fHVPkaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYxis5CMnYWkZRaSlllI WhYwsqxi5ChOLU7KTTcy2MQIjJKDW35b7GC8/NfmEKM0B4uSOO/Ht85BQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhiT/ZQtzmX66Lrz5fJtvKD4Q6zrQkJdVDLzJTv/f2+8/RKvXhE/8Cts mXdIckdWl8eFQrb9thku56bm7/gWsI9FeNP/bP5z5T+lp9RL9Ewx3Lv81cnMN+3LNz3U/Onz +E6d762ymPuXel3c73ef2SbG0f/K3npV27PU9wbfFt7+ybfUO6OB+6kSS3FGoqEWc1FxIgAh 5hGFYAIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 08:09:08 -0000 Hi, >>>I had the same reaction as Mark, if the consumer doesn't want to know=20 >>>about the sources then the MCU could simply just advertise a VC=20 >>>(main, slide) to represent the single stream from each site. >>> >>>A minimal implementation for switching could just specify=20 >>>MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker. This= =20 >>>would say the capture is a switched capture showing one capture at a=20 >>>time based on who is the active speaker, that is main and slides. >> >> Correct. >> >> >>>If you did want the whole source information in this case you are=20 >>>doing composition and switching so multiple MCCs would be needed. >>> >>>E.g. CaptureScene1 VC1(Main),VC2(Slides)=20 >>>MCC1(VC1,VC2,Maxcaptures=3D2(i.e. composed) >>>CaptureScene2 VC3(Main),VC4(Slides) >>>MCC2(VC3,VC4,Maxcaptures=3D2(i.e. composed) >>>CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=3D1 (i.e.=20 >>>switched),Policy=3Dactive speaker),encodinggroup >> >> I don't necessarily want the source information. But, I may want to=20 >> know e.g. which sites are used to compose the MCC content. But, maybe=20 >> such "metadata" can be provided using some composed attribute, or=20 >> something? >> >[CNG]"Site" information is related to the "CaptureScene" level. So to a ha= ve a "site/scene" level information at the capture level doesn't seem right= . >To capture the metadata for each "site" in an MCC: > >CaptureScene1(Description=3DSiteA,VC1) >CaptureScene2(Description=3DSiteB,VC2) >CaptrueScene3(Description=3DSiteC,VC3) >etc. >MCC(VC1,VC2,VC3,etc.) That works fine if the MCU always uses the same VC of each site to create t= he MCC.=20 But, if the MCC e.g. contains the active speaker of a site, the CaptureScen= e descriptions would need to include all VCs that might represent the activ= e speaker of a given site. So, again, I am not really interested in which VC of each site is used to c= reate the MCC, I am only interested to know that it represents the active s= peaker, and/or the slides, etc. Maybe something like: CaptureSceneMCU(Description=3DSiteA,SiteB,SiteC, MCC1) MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker Regards, Christer Because each of the VCs is in it's own CaptureScene this allows site level = metadata to be communicated to the consumer.The MCU may have received wildl= y different Advertisements from each of those sites. e.g.=20 those advertisements could have 10s of captures. The MCU has decided only t= o send very basic information to the consumer as to the sources of the MCC. > Also, I assume that an MCC doesn't necessarily have to be generated by=20 > an MCU. An endpoint could also advertise an MCC, e.g. the one in my=20 > example with main and slide. > > Regards, > > Christer > > > > > On 28/09/2013 1:30 AM, Christer Holmberg wrote: > > > > Hi Mark, > > > > Se comments inline. > > > > The currently proposal works when the content of an MCC is one or=20 > > more individual VCs, which the receiver can choose. That works fine=20 > > when the MCU does switching. > > > > But, in my opinion it does not work for composed MCCs, where the=20 > > content of the MCC can be built based on multiple > > > > Take an example: > > > > - in a conference, each site provides a CSE which contains two VCs: > > one with main video, and one with slides/screen sharing. > > > > - the MCU wants to provide, at any given time, one of these CSEs=20 > > (the selection might be based on active speaker, or whatever) is a=20 > > single stream towards an endpoint. So, it advertises an "main-slide=20 > > CSE from the site with the active speaker site" MCC. > > > > Now, I don't want the receiver to receive all the VCs, from the=20 > > different sites, and try to figure out which belong toghether etc. > > And, the more VCs an CSE consist of, the more complicated it gets. > > > > *//* > > > > */[Duckworth, Mark] If the MCU does not want to advertise anything=20 > > about the other endpoint's VCs, then what is the point of using an=20 > > MCC at all? In this case, the MCU should simply advertise a composed=20 > > VC./* > > > > *//* > > > > */[Christer] Sure, the MCU could do that. /* > > > > *//* > > > > */However, there are more to sites than the VCs. For example, I may=20 > > want to advertise which sites are used to compose the MCC content. > > (however, CSE may not be the best way to do that)./* > > > > *//* > > > > */Also, perhaps the MCU wants to advertise what type of video (e.g. > > main and slide) the VC is composed of. I guess I could do something=20 > > like MCC(MCC_Main, MCC_Slide), or something like that.../* > > > > *//* > > > > */Regards,/* > > > > *//* > > > > */Christer/* > > > > *//* > > > > Now, having said that, I DO agree that we should try to keep the=20 > > "hiearchy". > > > > So, in this case, maybe we should introduce a Mixed CSE (MCSE)=20 > > concept. The MCU could then offer a "most active site" MCSE, in=20 > > which it lists the MCC. Something like: MCSE1(MCC1{Policy > > SceneWithTheActiveSpeaker}) > > > > Regards, > > > > Christer > > > > -------------------------------------------------------------------- > > ---- > > > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of=20 > > Christian Groves [Christian.Groves@nteczone.com] > > *Sent:* Friday, 27 September 2013 3:57 AM > > *To:* clue@ietf.org > > *Subject:* Re: [clue] MCC with CSE > > > > Hello Christer, > > > > I had considered this issue when putting together the proposal and=20 > > decided that a CSE should be in a MCC. The idea behind the MCC was=20 > > that it was a capture. Captures go in CSEs not the other way around.=20 > > As Mark mentioned using CSEs inside MCCs would lead to nesting issues i= .e. > > CS,CSE,MCC,CSE. > > > > Also CSEs have a certain semantic that is that all the captures in=20 > > the CSE make up one representation of a scene. It shouldn't be seen=20 > > (pardon the pun) that CSEs is a syntax shorthand. I think there are=20 > > other options for minimising message size. > > > > Regards, Christian > > > > On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > > > > > Hi, > > > > > > It's up to the advertiser to make sure it doesn't advertise things=20 > > > that it can't provide. > > > > > > The MCU may request a specific CSE from an endpoint, and then=20 > > > advertise that as a composed MCC to another endpoint. I don't see=20 > > > why the MCU should have to advertise the VCs associated with that=20 > > > CSE, when it can simply advertise the CSE. > > > > > > Regards, > > > > > > Christer > > > > > >=20 > ---------------------------------------------------------------------- > -- > > > *From:* clue-bounces@ietf.org > > [clue-bounces@ietf.org] on behalf of > > > Duckworth, Mark [Mark.Duckworth@polycom.com] > > > *Sent:* Thursday, 26 September 2013 11:04 PM > > > *To:* CLUE > > > *Subject:* Re: [clue] MCC with CSE > > > > > > I think it would add complication and confusion to allow this. If=20 > > > allowed, it would be just a shorthand for saying "all the media=20 > > > captures in this CSE can be included in this MCC". But it also=20 > > > opens the door for nested MCCs (MCC includes a CSE that includes=20 > > > other MCCs), which doesn't make sense to me, so I suggest we just=20 > > > avoid this shorthand. > > > > > > Mark > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On=20 > > > Behalf Of *Christer Holmberg > > > *Sent:* Thursday, September 26, 2013 3:24 PM > > > *To:* CLUE > > > *Subject:* [clue] MCC with CSE > > > > > > Hi, > > > > > > There are some examples of CSEs which contain MCCs (e.g. > > > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to=20 > > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > > > > > An example is when the MCC is composed of a whole capture scene entry= . > > > > > > This is related to the discussion we previously had about=20 > > > simultaneous sets, where I said that it should be possible to=20 > > > advertise, and select, an CSE, rather than having to advertise and=20 > > > select each individual capture within. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org =20 > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org =20 > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Oct 1 06:19:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B092E21E8227 for ; Tue, 1 Oct 2013 06:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnCTGD+b75vT for ; Tue, 1 Oct 2013 06:19:30 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 9620F21E81B5 for ; Tue, 1 Oct 2013 06:19:14 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta06.westchester.pa.mail.comcast.net with comcast id XnnH1m0020EZKEL56pKE8x; Tue, 01 Oct 2013 13:19:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id XpKD1m00e3ZTu2S3MpKDoU; Tue, 01 Oct 2013 13:19:14 +0000 Message-ID: <524ACBD0.9040401@alum.mit.edu> Date: Tue, 01 Oct 2013 09:19:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380633554; bh=9JGemHZlh3xUU7rCJlMdvGmYdGH6EfHKbR1zPfjqoes=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ey+D2nlm4WEzYzE1RHYVhOVimG0EPVqUn9GCInWRbkvp7Je8gaqovpqbWDc3adfER y3K1sTyHcuZ6/mRpQrdV9Tz8N+M6gLUFmp7U28FbIlfHe33zVOOH+U9Iu2Xit+66O5 4VQw9goC+GaWim8op+gTpsZR/6zub9Qrmf8AkMhNfvFWFqJxrExfbPcwQo9K3hmm7V VnzsVkh83gbdkaFuAdXVYHfhloMCOWd6t4bXGN2h3dKwKkH3TzhuhyD+qej8WsQeWc 87RD+irpgwW+xLYqROnEdSE8OQPhHJIPuNg1EMZ2aNW8KPmZhpkTDkCw3/oBXENQhW iUuKPpFsG242Q== Subject: [clue] Slides for design team today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:19:34 -0000 You can find Christer's slides for today at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx See you shortly. Paul From mary.ietf.barnes@gmail.com Tue Oct 1 07:26:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A80511E8145 for ; Tue, 1 Oct 2013 07:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.501 X-Spam-Level: X-Spam-Status: No, score=-101.501 tagged_above=-999 required=5 tests=[AWL=-0.568, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwJCO+eoxpVS for ; Tue, 1 Oct 2013 07:26:10 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 124CD11E8192 for ; Tue, 1 Oct 2013 07:26:09 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c3so4778973qcv.18 for ; Tue, 01 Oct 2013 07:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DYVhZZJLVmlS3bkDYykOIp/PwZb2vq0e97tua/vrF+w=; b=YBp+63Y0E3RzIJqtKYoKQdPfPz8XUSrjUa1HkMtFjn9N25WOyEZjTdUmBev6tmVHNO 3deMdGhnUtAPZgS/f9itaXd0bi7DkLU02imjpFobdN7BvbYXMSaA8sYjHiFXt5X/om/I M3/HEG3clTMDOZnoLR4V5WMW6j3qZE5kCLCdetb3Sx+EuDwCKGcnNp1yup2YyGAnIaKG E82OrHF3rfTZLID3cTO/D/5yQZCFsvbfOn5cQOXj7OSvmFmfCVSPH6j2OU0Yvd+deNy1 GFgG6aM1FVePf7tbV875dL1qvZbnQC9KxQAymbh2jtLiu7lG6yK5oC2OL8VBG2kkdC2C acJg== MIME-Version: 1.0 X-Received: by 10.224.34.74 with SMTP id k10mr21800951qad.63.1380637567572; Tue, 01 Oct 2013 07:26:07 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 07:26:07 -0700 (PDT) In-Reply-To: <524ACBD0.9040401@alum.mit.edu> References: <524ACBD0.9040401@alum.mit.edu> Date: Tue, 1 Oct 2013 09:26:07 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c2cd78c77cc304e7aebbb0 Cc: CLUE Subject: Re: [clue] Slides for design team today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:26:11 -0000 --001a11c2cd78c77cc304e7aebbb0 Content-Type: text/plain; charset=ISO-8859-1 I'm in another meeting so unfortunately cannot attend today. But, I would really, really like to get away from the term "legacy" - the English language definition of "legacy" is not correct. CLUE isn't superseding any functionality of current SIP endpoints. It's adding additional functionality. I would much rather select something like "non-Clue enabled endpoint". We can shorten if folks are concerned about the length of a more appropriate alternative term. As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly more appropriate since it's a different architecture and entirely new application - i.e., it isn't based on RFC 3261, but CLUE is, so any suggestion that it's replacing any current SIP functionality isn't correct. Regards, Mary. On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat wrote: > You can find Christer's slides for today at: > > http://trac.tools.ietf.org/wg/**clue/trac/attachment/wiki/** > Design-Team/CLUE_Legacy_**1oct13.pptx > > See you shortly. > > Paul > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --001a11c2cd78c77cc304e7aebbb0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm in another meeting so unfortunately cannot attend = today. =A0But, I would really, really like to get away from the term "= legacy" -=A0=A0the English language definition of "legacy" i= s not correct.=A0CLUE isn't superseding any functionality of current SI= P endpoints. =A0It's adding additional functionality.=A0I would much ra= ther select something like "non-Clue enabled endpoint". =A0=A0We = can shorten if folks are concerned about the length of a more appropriate a= lternative term. =A0

As an aside, IMHO, the RTCWEB folks using the term "leg= acy" is slightly more appropriate since it's a different architect= ure and entirely new application - i.e., it isn't based on RFC 3261, bu= t CLUE is, so any suggestion that it's replacing any current SIP functi= onality isn't correct.

Regards,
Mary.


On Tue, Oct 1, 2013 at 8:19 AM, = Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
You can find Christer's slides for today= at:

http://trac.tools.ietf.org/w= g/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1o= ct13.pptx

See you shortly.

=A0 =A0 =A0 =A0 Paul
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--001a11c2cd78c77cc304e7aebbb0-- From pkyzivat@alum.mit.edu Tue Oct 1 09:23:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E7621E8223 for ; Tue, 1 Oct 2013 09:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-a-qy8OLfSI for ; Tue, 1 Oct 2013 09:23:15 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id F060411E8153 for ; Tue, 1 Oct 2013 09:22:59 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id XnCn1m0020ldTLk56sNxBo; Tue, 01 Oct 2013 16:22:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id XsNw1m00z3ZTu2S01sNxh7; Tue, 01 Oct 2013 16:22:57 +0000 Message-ID: <524AF6E0.2070205@alum.mit.edu> Date: Tue, 01 Oct 2013 12:22:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <524ACBD0.9040401@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380644577; bh=P1asAelfm37U8TQWGSjvn/PohTkxKnFqIWgTgRGz0J4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=efEXweJ+i4nul+Uj/ZKjV9BsD/BDZpsmWYrp8ICR8rneM0v17KS7ECMDobG/u+pp3 kkEGlWb4sEggytktNGoeDNOwGxOyJTgmnqM69Vx1yUG43sIsXiE5C9L2Xozkfsx33m eKNNJqe8SCSgMr8O2gvx682/FW+WW/TdUV42SEB/z1BTpo1zrmFcqfxJGUehJzUR6+ blduH8sC7BVezXH1jZO0Td2RfCRh0SpV+DHnrZf4YVTYxbf6ZiEwWNfUOFok9VTcLo Zwhe10pVWjnSU1eK+py/m80+YQtAX1cPh9kdrhld0+RAkPGe/UEza+zirJ79gO6VkN JpcOKqb/FIsrQ== Cc: CLUE Subject: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:23:27 -0000 Mary, The minutes are now posted. We did talk about this, briefly. We decided we didn't want to use the meeting time to discuss what word to use - that we could do that on the list. I agree with you, I also think "legacy" has the wrong connotation for what we mean, so I would like to find a better term. I have no ideas that I love, but a couple that I could live with: "non-clue", "clueless". Thanks, Paul On 10/1/13 10:26 AM, Mary Barnes wrote: > I'm in another meeting so unfortunately cannot attend today. But, I > would really, really like to get away from the term "legacy" - the > English language definition of "legacy" is not correct. CLUE isn't > superseding any functionality of current SIP endpoints. It's adding > additional functionality. I would much rather select something like > "non-Clue enabled endpoint". We can shorten if folks are concerned > about the length of a more appropriate alternative term. > > As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly > more appropriate since it's a different architecture and entirely new > application - i.e., it isn't based on RFC 3261, but CLUE is, so any > suggestion that it's replacing any current SIP functionality isn't correct. > > Regards, > Mary. > > > On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat > wrote: > > You can find Christer's slides for today at: > > http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx > > > See you shortly. > > Paul > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From rohanse2@cisco.com Tue Oct 1 09:45:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9978B21E812C for ; Tue, 1 Oct 2013 09:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5uxQZYOfikh for ; Tue, 1 Oct 2013 09:45:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 44D8C11E81B9 for ; Tue, 1 Oct 2013 09:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2263; q=dns/txt; s=iport; t=1380645898; x=1381855498; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=mxvDZ9tJDJKs0KAvH2WZkYFeu96E46qa3sAF56hOBvM=; b=X84ygXqdQzPtuJ4qBXW0KAU836NcXaZbFalO+/lC52An43q/qtfkC+QE WSa0dAGX9dvHQm7Bw7fQO6kIgh7COIiUD9jawrL+EOttibWwixIcvX4EA zmIZ1o08YqJcC+K63rDrXCdKVnSxqRyJJJre/bhfeEyv5yY3K3Byia/Bu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4KAOj6SlKQ/khL/2dsb2JhbABagwc4rQmUToEwFnSCJQEBAQMBAQEBNTYKBgsLEgYJFggHCQMCAQIBFR8DDhMGAgEBh3wGDL0Ej1gWhAwDl3+BL4UEi0eDJTs X-IronPort-AV: E=Sophos;i="4.90,1014,1371081600"; d="scan'208";a="160210628" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Oct 2013 16:44:52 +0000 Received: from [10.47.196.64] ([10.47.196.64]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r91GimKX029047 for ; Tue, 1 Oct 2013 16:44:50 GMT Message-ID: <524AFC21.7070106@cisco.com> Date: Tue, 01 Oct 2013 17:45:21 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> In-Reply-To: <524AF6E0.2070205@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:45:06 -0000 I am personally very fond of 'CLUEless' :) Rob On 01/10/2013 17:22, Paul Kyzivat wrote: > Mary, > > The minutes are now posted. We did talk about this, briefly. > We decided we didn't want to use the meeting time to discuss what word > to use - that we could do that on the list. > > I agree with you, I also think "legacy" has the wrong connotation for > what we mean, so I would like to find a better term. I have no ideas > that I love, but a couple that I could live with: "non-clue", "clueless". > > Thanks, > Paul > > On 10/1/13 10:26 AM, Mary Barnes wrote: >> I'm in another meeting so unfortunately cannot attend today. But, I >> would really, really like to get away from the term "legacy" - the >> English language definition of "legacy" is not correct. CLUE isn't >> superseding any functionality of current SIP endpoints. It's adding >> additional functionality. I would much rather select something like >> "non-Clue enabled endpoint". We can shorten if folks are concerned >> about the length of a more appropriate alternative term. >> >> As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly >> more appropriate since it's a different architecture and entirely new >> application - i.e., it isn't based on RFC 3261, but CLUE is, so any >> suggestion that it's replacing any current SIP functionality isn't >> correct. >> >> Regards, >> Mary. >> >> >> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat > > wrote: >> >> You can find Christer's slides for today at: >> >> >> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx >> >> >> >> >> >> See you shortly. >> >> Paul >> _________________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/__listinfo/clue >> >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Oct 1 09:51:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AC511E8143 for ; Tue, 1 Oct 2013 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.476 X-Spam-Level: X-Spam-Status: No, score=-101.476 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iEVaqoXgjiU for ; Tue, 1 Oct 2013 09:51:30 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6800111E8129 for ; Tue, 1 Oct 2013 09:51:30 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so5097208qej.25 for ; Tue, 01 Oct 2013 09:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00ciMYgPvD8Fi8TofXkz73ZUisISlixJglK4OzeBaLY=; b=godiWeX5xx8uAKBy4FyAdKth7t4OczF2a6G0pA9gvLWwKUph62hHgOkn0qwk0mayQX mJLrZ18h7Tq+76nJM4LX13HWI269Vyb6gpYevQnOUPGmODhE2G48+0ZrULdIKB96Pvxc XTdk0mw2eYijXT05r535L+d4u5HXug2plIjlNqVqDZuSrFJlBBKha3AKQ0Oz0c6i9pCJ yGQI2gLyaHNKT3KtmFwRZiWKluHlXz31KPWDd8BO3JeF1OWAdeiS6K3faG+hFYTySne+ wC0L3EimUs/s80DP9S5naHj02ofvjv9aVzTsYfeoY1OSKPK30pDASf85hKhu++Oxpn2U 6xfQ== MIME-Version: 1.0 X-Received: by 10.49.51.67 with SMTP id i3mr37128691qeo.8.1380646287695; Tue, 01 Oct 2013 09:51:27 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 09:51:27 -0700 (PDT) In-Reply-To: <524AFC21.7070106@cisco.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> Date: Tue, 1 Oct 2013 11:51:27 -0500 Message-ID: From: Mary Barnes To: Robert Hansen Content-Type: multipart/alternative; boundary=047d7bdc0b6e89e5fb04e7b0c3b2 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:51:31 -0000 --047d7bdc0b6e89e5fb04e7b0c3b2 Content-Type: text/plain; charset=ISO-8859-1 Yeah - I think clueless is a reasonable and compact term to use. On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen wrote: > I am personally very fond of 'CLUEless' :) > > Rob > > > On 01/10/2013 17:22, Paul Kyzivat wrote: > >> Mary, >> >> The minutes are now posted. We did talk about this, briefly. >> We decided we didn't want to use the meeting time to discuss what word >> to use - that we could do that on the list. >> >> I agree with you, I also think "legacy" has the wrong connotation for >> what we mean, so I would like to find a better term. I have no ideas >> that I love, but a couple that I could live with: "non-clue", "clueless". >> >> Thanks, >> Paul >> >> On 10/1/13 10:26 AM, Mary Barnes wrote: >> >>> I'm in another meeting so unfortunately cannot attend today. But, I >>> would really, really like to get away from the term "legacy" - the >>> English language definition of "legacy" is not correct. CLUE isn't >>> superseding any functionality of current SIP endpoints. It's adding >>> additional functionality. I would much rather select something like >>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>> about the length of a more appropriate alternative term. >>> >>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly >>> more appropriate since it's a different architecture and entirely new >>> application - i.e., it isn't based on RFC 3261, but CLUE is, so any >>> suggestion that it's replacing any current SIP functionality isn't >>> correct. >>> >>> Regards, >>> Mary. >>> >>> >>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >> **> wrote: >>> >>> You can find Christer's slides for today at: >>> >>> >>> http://trac.tools.ietf.org/wg/**__clue/trac/attachment/wiki/__** >>> Design-Team/CLUE_Legacy___**1oct13.pptx >>> >>> >>> >> Design-Team/CLUE_Legacy_**1oct13.pptx >>> > >>> >>> >>> See you shortly. >>> >>> Paul >>> ______________________________**___________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/_**_listinfo/clue >>> >>> > >>> >>> >>> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7bdc0b6e89e5fb04e7b0c3b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah - I think clueless is a reasonable and compact term t= o use.


O= n Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen <rohanse2@cisco.com>= wrote:
I am personally very fond of 'CLUEless&#= 39; :)

Rob


On 01/10/2013 17:22, Paul Kyzivat wrote:
Mary,

The minutes are now posted. We did talk about this, briefly.
We decided we didn't want to use the meeting time to discuss what word<= br> to use - that we could do that on the list.

I agree with you, I also think "legacy" has the wrong connotation= for
what we mean, so I would like to find a better term. I have no ideas
that I love, but a couple that I could live with: "non-clue", &qu= ot;clueless".

=A0 =A0 =A0Thanks,
=A0 =A0 =A0Paul

On 10/1/13 10:26 AM, Mary Barnes wrote:
I'm in another meeting so unfortunately cannot attend today. =A0But, I<= br> would really, really like to get away from the term "legacy" - = =A0the
English language definition of "legacy" is not correct. CLUE isn&= #39;t
superseding any functionality of current SIP endpoints. =A0It's adding<= br> additional functionality. I would much rather select something like
"non-Clue enabled endpoint". =A0 We can shorten if folks are conc= erned
about the length of a more appropriate alternative term.

As an aside, IMHO, the RTCWEB folks using the term "legacy" is sl= ightly
more appropriate since it's a different architecture and entirely new application - i.e., it isn't based on RFC 3261, but CLUE is, so any
suggestion that it's replacing any current SIP functionality isn't<= br> correct.

Regards,
Mary.


On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 You can find Christer's slides for today at:


http://trac.tools.ietf= .org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy= ___1oct13.pptx


<http://trac.tools.ietf.o= rg/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx>


=A0 =A0 See you shortly.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
=A0 =A0 _________________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7bdc0b6e89e5fb04e7b0c3b2-- From christer.holmberg@ericsson.com Tue Oct 1 11:16:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BF921E81BA for ; Tue, 1 Oct 2013 11:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.819 X-Spam-Level: X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp3O-W3ND0-X for ; Tue, 1 Oct 2013 11:16:09 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE01521E812C for ; Tue, 1 Oct 2013 11:16:08 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-70-524b1166963c Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 92.06.16099.6611B425; Tue, 1 Oct 2013 20:16:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0328.009; Tue, 1 Oct 2013 20:16:06 +0200 From: Christer Holmberg To: Mary Barnes , Robert Hansen Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOvsKWUVs+qhhkEE2in1P/xTqM7pnf7C+AgAABtYCAADiqQIAAAIYy Date: Tue, 1 Oct 2013 18:16:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B15A8@ESESSMB209.ericsson.se> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B15A8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+JvrW66oHeQwcn/LBb7T11mtvi8fz+z xaf/H9gdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZbTuDyt44FOx87BiA+ND xy5GTg4JAROJS2+OskHYYhIX7q0Hsrk4hAQOM0qcXv2dGcJZzCixaXUrUxcjBwebgIVE9z9t kAYRgSCJHbcesYPYzAISEqsufmAEKREW0JXYsl0QokRP4u7viawQtpvEvXX3mEFsFgEViS93 WsFsXgFfieff57BArPrBKHH1eysjSIJTIFBi15YfYDYj0HHfT61hgtglLnHryXwmiKMFJJbs Oc8MYYtKvHz8jxXCVpRof9rACFGfL7Hi30J2iGWCEidnPmGZwCg6C8moWUjKZiEpg4jrSdyY OoUNwtaWWLbwNTOErSsx498hqBpriYZvR1HULGDkWMXInpuYmZNebriJERh7B7f81t3BeOqc yCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwNny/tOC/ruMd3QbpySd9 n/i3ME3bwRvAqrTCavviLVqCi6Z8uTEt3Hp7mWTPhFX+33IFPz7d4imkcn9z1UkXf4kDQqI7 2P/0JyjvUvlWsiI3qffV5PO7eI5pTZOYcuNmKFPVU6bXV+dLJs6fM3mO8AcmZ0Yt05Na868x +Z5Y8ix4SaX+hglLGJRYijMSDbWYi4oTAaR6ptSLAgAA Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:16:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B15A8ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am not saying we can't use 'clueless', but I want a term that I can use a= nd reference outside CLUE, e.g. in 3GPP specifications. So, we also need so= me definition text. I can work on that, and suggest something, as part of t= he lega... eeeeh... clueless interworking task. Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Tuesday, 01 October 2013 7:51 PM To: Robert Hansen Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? Yeah - I think clueless is a reasonable and compact term to use. On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen > wrote: I am personally very fond of 'CLUEless' :) Rob On 01/10/2013 17:22, Paul Kyzivat wrote: Mary, The minutes are now posted. We did talk about this, briefly. We decided we didn't want to use the meeting time to discuss what word to use - that we could do that on the list. I agree with you, I also think "legacy" has the wrong connotation for what we mean, so I would like to find a better term. I have no ideas that I love, but a couple that I could live with: "non-clue", "clueless". Thanks, Paul On 10/1/13 10:26 AM, Mary Barnes wrote: I'm in another meeting so unfortunately cannot attend today. But, I would really, really like to get away from the term "legacy" - the English language definition of "legacy" is not correct. CLUE isn't superseding any functionality of current SIP endpoints. It's adding additional functionality. I would much rather select something like "non-Clue enabled endpoint". We can shorten if folks are concerned about the length of a more appropriate alternative term. As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly more appropriate since it's a different architecture and entirely new application - i.e., it isn't based on RFC 3261, but CLUE is, so any suggestion that it's replacing any current SIP functionality isn't correct. Regards, Mary. On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >> wrote: You can find Christer's slides for today at: http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLU= E_Legacy___1oct13.pptx See you shortly. Paul _________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C4B15A8ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <32D02C7B3E528F4EA3665BEA171D73F6@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

I am not saying we can't use 'clueless', but I want a term that I can us= e and reference outside CLUE, e.g. in 3GPP specifications. So, we also need= some definition text. I can work on that, and suggest something, as part o= f the lega... eeeeh... clueless interworking task.

 

Regards,

 

Christer

 

 

 

From: clue-bounces@ietf.org [clue-bounces= @ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Tuesday, 01 October 2013 7:51 PM
To: Robert Hansen
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

Yeah - I think clueless is a reasonable and compact term t= o use.


On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen <= span dir=3D"ltr"> <rohanse2@cisco.= com> wrote:
I am personally very fond of 'CLUEless' :)

Rob


On 01/10/2013 17:22, Paul Kyzivat wrote:
Mary,

The minutes are now posted. We did talk about this, briefly.
We decided we didn't want to use the meeting time to discuss what word
to use - that we could do that on the list.

I agree with you, I also think "legacy" has the wrong connotation= for
what we mean, so I would like to find a better term. I have no ideas
that I love, but a couple that I could live with: "non-clue", &qu= ot;clueless".

     Thanks,
     Paul

On 10/1/13 10:26 AM, Mary Barnes wrote:
I'm in another meeting so unfortunately cannot attend today.  But, I would really, really like to get away from the term "legacy" - &n= bsp;the
English language definition of "legacy" is not correct. CLUE isn'= t
superseding any functionality of current SIP endpoints.  It's adding additional functionality. I would much rather select something like
"non-Clue enabled endpoint".   We can shorten if folks are c= oncerned
about the length of a more appropriate alternative term.

As an aside, IMHO, the RTCWEB folks using the term "legacy" is sl= ightly
more appropriate since it's a different architecture and entirely new
application - i.e., it isn't based on RFC 3261, but CLUE is, so any
suggestion that it's replacing any current SIP functionality isn't
correct.

Regards,
Mary.


On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

    You can find Christer's slides for today at:


http://trac.tools.ietf= .org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy= ___1oct13.pptx


<http://trac.tools.ietf.o= rg/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx>


    See you shortly.

             Paul
    _________________________________________________
    clue mailing list
    clue@ietf.= org <mailto:clue@= ietf.org>
    https://www.ietf.org/mailman/__listinfo/clue
    <https://www.ietf.org/mailman/listinfo/clue>


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--_000_7594FB04B1934943A5C02806D1A2204B1C4B15A8ESESSMB209erics_-- From mary.ietf.barnes@gmail.com Tue Oct 1 11:35:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A2D21E81BA for ; Tue, 1 Oct 2013 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.466 X-Spam-Level: X-Spam-Status: No, score=-101.466 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVtNetlx0B+5 for ; Tue, 1 Oct 2013 11:35:33 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9240821E81B9 for ; Tue, 1 Oct 2013 11:35:33 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j7so3623066qaq.5 for ; Tue, 01 Oct 2013 11:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6TnMq2I0DDPFqNIBhoP+Kl3kBZAKMnaT1QFxMt9iLY0=; b=US6YuBa4MHZrCGKdCGXsqKwIzyOBapzYZ7MlGA3dkfl+Gqbxvxj8Sq/4hAaxOeqpFW G/0q7nd8+kdCK2PYPUB4PwD9Jnr0G4D/grXUyWC1Jx3sjhSb48jIVDtUXKuAImiLCz7O r3yI66ACdjrmOFTIIo0DZonXecbGgbmmFUoAiUoTkf1Sq8T4ElIYdMEAVbP7C40BXbQL l9gaaE7WZhFtT9VvoV3BiEkV47jmyxejDWZq4t19izGEPg0I2RhJiuayZOlBf0uyUJnR BS8c49DiGkcuTZwQhDtey7oZIgU9UQvbZ7aTcMZe/LcllGl7WTxwc2mxiIbD83xaSLmx OnMA== MIME-Version: 1.0 X-Received: by 10.229.127.74 with SMTP id f10mr37495262qcs.16.1380652531900; Tue, 01 Oct 2013 11:35:31 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 1 Oct 2013 11:35:31 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B15A8@ESESSMB209.ericsson.se> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4B15A8@ESESSMB209.ericsson.se> Date: Tue, 1 Oct 2013 13:35:31 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1133dd4cb8e7cc04e7b2375c Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:35:36 -0000 --001a1133dd4cb8e7cc04e7b2375c Content-Type: text/plain; charset=ISO-8859-1 Sure. We can make a definition for the term "clueless", something like: A SIP endpoint that is not enabled to support the CLUE protocol and required SDP/RTP extensions. We have this concept in XCON and we just use the term non-XCON enabled client (but we didn't have the convenience of a catch term to use in place of the expanded term ;) Mary. On Tue, Oct 1, 2013 at 1:16 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I am not saying we can't use 'clueless', but I want a term that I can use > and reference outside CLUE, e.g. in 3GPP specifications. So, we also need > some definition text. I can work on that, and suggest something, as part of > the lega... eeeeh... clueless interworking task. > > > > Regards, > > > > Christer > > > > > > > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary > Barnes [mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, 01 October 2013 7:51 PM > *To:* Robert Hansen > *Cc:* CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > Yeah - I think clueless is a reasonable and compact term to use. > > > On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen wrote: > >> I am personally very fond of 'CLUEless' :) >> >> Rob >> >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >> >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what word >>> to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", "clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>> >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly >>>> more appropriate since it's a different architecture and entirely new >>>> application - i.e., it isn't based on RFC 3261, but CLUE is, so any >>>> suggestion that it's replacing any current SIP functionality isn't >>>> correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>> **> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/**__clue/trac/attachment/wiki/__** >>>> Design-Team/CLUE_Legacy___**1oct13.pptx >>>> >>>> >>>> >>> Design-Team/CLUE_Legacy_**1oct13.pptx >>>> > >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> ______________________________**___________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/_**_listinfo/clue >>>> >>>> > >>>> >>>> >>>> >>> ______________________________**_________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/**listinfo/clue >>> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > --001a1133dd4cb8e7cc04e7b2375c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sure. We can make a definition for the term "clueless= ", something like:
A SIP endpoint that is not enabled to support t= he CLUE protocol and required SDP/RTP extensions.=A0

We have this concept in XCON and we just use the term non-XCON enabled clie= nt (but we didn't have the convenience of a catch term to use in place = of the expanded term ;)=A0

Mary.=A0


On Tue, Oct 1, 2013 at 1:16 PM, Christer= Holmberg <christer.holmberg@ericsson.com> wrot= e:

Hi,

=A0

I am not saying we can't use 'clueless', but I want a term t= hat I can use and reference outside CLUE, e.g. in 3GPP specifications. So, = we also need some definition text. I can work on that, and suggest somethin= g, as part of the lega... eeeeh... clueless interworking task.

=A0

Regards,

=A0

Christer

=A0

=A0

=A0

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]=
Sent: Tuesday, 01 October 2013 7:51 PM
To: Robert Hansen
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

Yeah - I think clueless is a reasonable and compact term t= o use.


On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen <= span dir=3D"ltr"> <rohanse2@cisco.= com> wrote:
I am personally very fond of 'CLUEless' :)

Rob


On 01/10/2013 17:22, Paul Kyzivat wrote:
Mary,

The minutes are now posted. We did talk about this, briefly.
We decided we didn't want to use the meeting time to discuss what word<= br> to use - that we could do that on the list.

I agree with you, I also think "legacy" has the wrong connotation= for
what we mean, so I would like to find a better term. I have no ideas
that I love, but a couple that I could live with: "non-clue", &qu= ot;clueless".

=A0 =A0 =A0Thanks,
=A0 =A0 =A0Paul

On 10/1/13 10:26 AM, Mary Barnes wrote:
I'm in another meeting so unfortunately cannot attend today. =A0But, I<= br> would really, really like to get away from the term "legacy" - = =A0the
English language definition of "legacy" is not correct. CLUE isn&= #39;t
superseding any functionality of current SIP endpoints. =A0It's adding<= br> additional functionality. I would much rather select something like
"non-Clue enabled endpoint". =A0 We can shorten if folks are conc= erned
about the length of a more appropriate alternative term.

As an aside, IMHO, the RTCWEB folks using the term "legacy" is sl= ightly
more appropriate since it's a different architecture and entirely new application - i.e., it isn't based on RFC 3261, but CLUE is, so any
suggestion that it's replacing any current SIP functionality isn't<= br> correct.

Regards,
Mary.


On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 You can find Christer's slides for today at:


http://trac.tools.ietf= .org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy= ___1oct13.pptx


<http://trac.tools.ietf.o= rg/wg/clue/trac/attachment/wiki/Design-Team/CLUE_Legacy_1oct13.pptx>


=A0 =A0 See you shortly.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
=A0 =A0 _________________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--001a1133dd4cb8e7cc04e7b2375c-- From pkyzivat@alum.mit.edu Tue Oct 1 14:40:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315A221F9FBF for ; Tue, 1 Oct 2013 14:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwcZFihTz-FQ for ; Tue, 1 Oct 2013 14:40:38 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2503621F9F50 for ; Tue, 1 Oct 2013 14:40:31 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta01.westchester.pa.mail.comcast.net with comcast id Xw4w1m00417dt5G51xgWmh; Tue, 01 Oct 2013 21:40:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id XxgV1m01A3ZTu2S3ZxgWfL; Tue, 01 Oct 2013 21:40:30 +0000 Message-ID: <524B414C.2030406@alum.mit.edu> Date: Tue, 01 Oct 2013 17:40:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> In-Reply-To: <524AFC21.7070106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380663630; bh=GN7uXUDggL0uEatSQxZ7c280ZNwbG+9cg5yqZOewrEY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=p2fhVYCSv8kQbpAlfIUXd4gjerbj6sKESVL9PNJo0rZgHFxjpxW8rAhl0otfRTJwv LVqg7Gbj/OrtxhrtpoYQRb04kVuatU9JbelrJzD+bPns2mGp84Zt9Fs5Oc00zJG8T5 yBDf/rSU7d3WRSMupprvZkKGaxqubf9sH+ULF64G1dJLY3XF8QEX1n3xdDTNWDEy7T iyTVoNWiwkWVPLvO1cf0VQF5HasLZ4spIRWSxEQ6CHXTN2ZY8IemvBvjOmhoBjOIHP TUlHExNmUZfaRaD1C+qjN8HXm/mEY14DNNUqb02ghNUs1Udlda9OhDa04jGSC/0V5q AJQVj1ifxEW+Q== Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:40:49 -0000 On 10/1/13 12:45 PM, Robert Hansen wrote: > I am personally very fond of 'CLUEless' :) One of the reasons I liked the name "clue" for the wg was because it gave us an excuse to use "clueless" and "clueful". However they do have the feel of "informal" usage - a bit odd for formal use. (But I can get over that.) Thanks, Paul > Rob > > On 01/10/2013 17:22, Paul Kyzivat wrote: >> Mary, >> >> The minutes are now posted. We did talk about this, briefly. >> We decided we didn't want to use the meeting time to discuss what word >> to use - that we could do that on the list. >> >> I agree with you, I also think "legacy" has the wrong connotation for >> what we mean, so I would like to find a better term. I have no ideas >> that I love, but a couple that I could live with: "non-clue", "clueless". >> >> Thanks, >> Paul >> >> On 10/1/13 10:26 AM, Mary Barnes wrote: >>> I'm in another meeting so unfortunately cannot attend today. But, I >>> would really, really like to get away from the term "legacy" - the >>> English language definition of "legacy" is not correct. CLUE isn't >>> superseding any functionality of current SIP endpoints. It's adding >>> additional functionality. I would much rather select something like >>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>> about the length of a more appropriate alternative term. >>> >>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is slightly >>> more appropriate since it's a different architecture and entirely new >>> application - i.e., it isn't based on RFC 3261, but CLUE is, so any >>> suggestion that it's replacing any current SIP functionality isn't >>> correct. >>> >>> Regards, >>> Mary. >>> >>> >>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >> > wrote: >>> >>> You can find Christer's slides for today at: >>> >>> >>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx >>> >>> >>> >>> >>> >>> >>> >>> See you shortly. >>> >>> Paul >>> _________________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/__listinfo/clue >>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Oct 1 14:50:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F12C21E81FA for ; Tue, 1 Oct 2013 14:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1rTKnjEU2Hs for ; Tue, 1 Oct 2013 14:50:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id B3F0921E808C for ; Tue, 1 Oct 2013 14:49:56 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id XnXH1m0030vyq2s5FxpwVQ; Tue, 01 Oct 2013 21:49:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Xxpv1m0113ZTu2S3RxpwdY; Tue, 01 Oct 2013 21:49:56 +0000 Message-ID: <524B4382.60708@alum.mit.edu> Date: Tue, 01 Oct 2013 17:49:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380664196; bh=wTAqwWEUrMtqqz/XO0ZaDKQ5gbE91Qcmqw4IamZ6M0M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fJaGVi9ZyVjWF/VozA3DrvQV85YnSUtfO/mRNynHJIeLOPtpEfkhG+VkENkv4KNW8 FuMD+euRxZ07EOc8lp3XhUjp+6TYkxn5IkGc3SoRw69uzkZYEF3nHrb8J3uqJM+i98 YYqn/iYYXndBYlvZ/IkfvayPEVbPp9Yf5d6dhYGiLIoupqMMva2xeqwZbYIECg0CW3 zxF/wA9HpiYB1GACSbzlSaoGWwUXM6EzEo/2/18CvBqR+2a4X9LN+hSqb+EkQZSZbX ajN39ZI+iGskzOhyhU4IYWXIJ8V9g/nq3oMkXwXJ6xfkfP+MMEj1BkM3XiLsgszQ6D DFKDRbbBRjLLA== Subject: Re: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:50:29 -0000 Mark, On 9/30/13 1:18 PM, Duckworth, Mark wrote: > I propose keeping the first three paragraphs as is. And change the rest > to something like this: > > ==== begin proposed======================================== > > > > Individual Encoding parameters are represented in SDP [RFC4566], not > in CLUE messages. For example, for a video encoding using H.26x > compression technologies, this can include parameters such as: > > ·Maximum bandwidth; > > ·Maximum picture size in pixels; > > ·Maxmimum number of pixels to be processed per second; > > The bandwidth parameter is the only one that specifically relates to a > CLUE Advertisement, as it can be further constrained by the maximum > group bandwidth in an Encoding Group. > > ==== end proposed ======================================== The above is dependent on encodings being expressed only in SDP. That is still up in the air. Rob is in the process of analyzing the pros/cons of having them SDP and having them in the Advertisement. I think a final resolution of *this* will have to wait until that is decided. But you can still do this for now, and change later if need be. Thanks, Paul From Christian.Groves@nteczone.com Tue Oct 1 17:57:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA911E8153 for ; Tue, 1 Oct 2013 17:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8yYkQX0fVVp for ; Tue, 1 Oct 2013 17:57:18 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 4F07711E8188 for ; Tue, 1 Oct 2013 17:57:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALhuS1J20fqk/2dsb2JhbAANS8UfgUCDGgEBBDgbJQEQCyEWDwkDAgECAUUGDQEHAQGyDZM3j1EHhCIDrS8 Received: from ppp118-209-250-164.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.250.164]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Oct 2013 10:27:14 +0930 Message-ID: <524B6F63.8060108@nteczone.com> Date: Wed, 02 Oct 2013 10:57:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 00:57:24 -0000 Hello Christer, ..snip.. >> [CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right. >> To capture the metadata for each "site" in an MCC: >> >> CaptureScene1(Description=SiteA,VC1) >> CaptureScene2(Description=SiteB,VC2) >> CaptrueScene3(Description=SiteC,VC3) >> etc. >> MCC(VC1,VC2,VC3,etc.) > That works fine if the MCU always uses the same VC of each site to create the MCC. [CNG] VC1 is just a logical representation, it doesn't have to be one of the source captures that the MCU received. > > But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site. [CNG] No it doesn't. The VC in this case is only used as a logical entity to represent the site. There's no capture encoding. The MCU may wish to advertise all the source captures or produce its own captures based on the source information. > > So, again, I am not really interested in which VC of each site is used to create the MCC, I am only interested to know that it represents the active speaker, and/or the slides, etc. > > Maybe something like: > > CaptureSceneMCU(Description=SiteA,SiteB,SiteC, MCC1) > MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker [CNG] I guess you mean MCC1() in the 2nd line? It could work although "Description" currently doesn't allow multiple values and is an unstructured string so the consumer may not understand that there are essentially multiple values. > > regards, Christian From Christian.Groves@nteczone.com Tue Oct 1 20:29:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7D21E8268 for ; Tue, 1 Oct 2013 20:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5sKyp-Q69C9 for ; Tue, 1 Oct 2013 20:29:45 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id A2BD921E8279 for ; Tue, 1 Oct 2013 20:29:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAOuRS1J20fqk/2dsb2JhbAANS4M/wWeBQYMZAQEBBAEBATUbGwoRCxEBAwEBAQkWCAcJAwIBAgEPBh8DBggTBgIBAYdwAxuqBIlEDYlqjGaCcoQiA5YWgxiLFohr Received: from ppp118-209-250-164.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.250.164]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Oct 2013 12:59:34 +0930 Message-ID: <524B9319.4050906@nteczone.com> Date: Wed, 02 Oct 2013 13:29:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4B15A8@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 03:29:52 -0000 I'm not sure that "CLUEless" is the same as "legacy". "Legacy" seems to imply the absence of the CLUE protocol AND a certain "media stream configuration". I think Christer's slides from the design team meeting illustrated this. CLUEless to me suggests that the CLUE channel has been removed (along with the CLUE specific SDP) it doesn't suggest a fall back to a base media set. I think this is fine as CLUE and SDP (which does the fallback) are and should be decoupled. So if we are talking about "fallback to legacy" an equivalent would be to say "reverting to a CLUEless session with a basic media configuration". With regards to the definition of CLUEless: the one below seems to focus on endpoint, you could also have a clueless session. I.e. the endpoint is CLUE enabled but doesn't use CLUE for the session. Perhaps it would be sufficient to say: "CLUEless: Indicates an absence of the CLUE protocol"? Christian On 2/10/2013 4:35 AM, Mary Barnes wrote: > Sure. We can make a definition for the term "clueless", something like: > A SIP endpoint that is not enabled to support the CLUE protocol and > required SDP/RTP extensions. > > We have this concept in XCON and we just use the term non-XCON enabled > client (but we didn't have the convenience of a catch term to use in > place of the expanded term ;) > > Mary. > > > On Tue, Oct 1, 2013 at 1:16 PM, Christer Holmberg > > wrote: > > Hi, > > I am not saying we can't use 'clueless', but I want a term that I > can use and reference outside CLUE, e.g. in 3GPP specifications. > So, we also need some definition text. I can work on that, and > suggest something, as part of the lega... eeeeh... clueless > interworking task. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org > [clue-bounces@ietf.org ] on behalf > of Mary Barnes [mary.ietf.barnes@gmail.com > ] > *Sent:* Tuesday, 01 October 2013 7:51 PM > *To:* Robert Hansen > *Cc:* CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > Yeah - I think clueless is a reasonable and compact term to use. > > > On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen > wrote: > > I am personally very fond of 'CLUEless' :) > > Rob > > > On 01/10/2013 17:22, Paul Kyzivat wrote: > > Mary, > > The minutes are now posted. We did talk about this, briefly. > We decided we didn't want to use the meeting time to > discuss what word > to use - that we could do that on the list. > > I agree with you, I also think "legacy" has the wrong > connotation for > what we mean, so I would like to find a better term. I > have no ideas > that I love, but a couple that I could live with: > "non-clue", "clueless". > > Thanks, > Paul > > On 10/1/13 10:26 AM, Mary Barnes wrote: > > I'm in another meeting so unfortunately cannot attend > today. But, I > would really, really like to get away from the term > "legacy" - the > English language definition of "legacy" is not > correct. CLUE isn't > superseding any functionality of current SIP > endpoints. It's adding > additional functionality. I would much rather select > something like > "non-Clue enabled endpoint". We can shorten if folks > are concerned > about the length of a more appropriate alternative term. > > As an aside, IMHO, the RTCWEB folks using the term > "legacy" is slightly > more appropriate since it's a different architecture > and entirely new > application - i.e., it isn't based on RFC 3261, but > CLUE is, so any > suggestion that it's replacing any current SIP > functionality isn't > correct. > > Regards, > Mary. > > > On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat > > >> wrote: > > You can find Christer's slides for today at: > > > http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Team/CLUE_Legacy___1oct13.pptx > > > > > > See you shortly. > > Paul > _________________________________________________ > clue mailing list > clue@ietf.org > > > https://www.ietf.org/mailman/__listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Oct 1 20:35:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C647F21E826C for ; Tue, 1 Oct 2013 20:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxl0kL+maKDl for ; Tue, 1 Oct 2013 20:35:08 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF821E825B for ; Tue, 1 Oct 2013 20:35:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0BAAKTS1J20fqk/2dsb2JhbAANS8UcAYFKbYJrGxsKPRYYAwIBAgFLDQgBAbIWkzqTegOtLw Received: from ppp118-209-250-164.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.250.164]) by ipmail05.adl6.internode.on.net with ESMTP; 02 Oct 2013 13:05:03 +0930 Message-ID: <524B9464.7060708@nteczone.com> Date: Wed, 02 Oct 2013 13:35:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] MCC in framework? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 03:35:14 -0000 Hello all, We've had some discussion on the mailing list regarding the MCC concept? The response seems to be cautiously positive. Is this something that people are happy to move forward with in the framework? I'd be happy to work with Mark for some text for the framework. At least if there's text then we can iron out any issues. There is still the issue of full updates vs deltas but I don't think that's a specific problem of the MCC concept. Regards, Christian From christer.holmberg@ericsson.com Wed Oct 2 00:42:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1821F9E76 for ; Wed, 2 Oct 2013 00:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yK4EMm2r3Z9 for ; Wed, 2 Oct 2013 00:42:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBAE21F9E6C for ; Wed, 2 Oct 2013 00:42:35 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-47-524bce6a3e57 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DA.DE.03802.A6ECB425; Wed, 2 Oct 2013 09:42:34 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0328.009; Wed, 2 Oct 2013 09:42:12 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOvsKWUVs+qhhkEE2in1P/xTqM7pnf7C+AgAABtYCAADiqQIAAAIYy///j44CAAJUwgIAAZtmQ Date: Wed, 2 Oct 2013 07:42:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B1B66@ESESSMB209.ericsson.se> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C4B15A8@ESESSMB209.ericsson.se> <524B9319.4050906@nteczone.com> In-Reply-To: <524B9319.4050906@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrW7WOe8gg7ftJhZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mo4/2wzU0GTZUX/+sVMDYzv1LsYOTkkBEwk tu78xA5hi0lcuLeerYuRi0NI4DCjxPMJy1ggnMWMEmdfX2fuYuTgYBOwkOj+pw3SICIQLtGx 7QojSFhYQFdiy3ZBiLCexN3fE1kh7CiJtZ2XGEFsFgEViekXN4Dt4hXwlbh86TcziC0ksJRZ 4nWbDojNKaAjMWH/A7B6RqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwFSU+ vtrHCFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZ OenlRpsYgZFwcMtv1R2Md86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAMji3TOl4sP3//cHbDync2Si2taXh4VPZdSH/B18cHSoMTXSp+Vpj+KtGGuVs9M8ur7qpvw qE3kcSLrGUfuvRwSPskHrzw/7hpw6GXOypa51tdyCpI3Rzjwzc2a7yxeG70tacIZoS+36+ok lmrpc29LXVJx4dzcZxJGTHx3O9pO/Kh58+bsKcU8JZbijERDLeai4kQAWfmSX1ICAAA= Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 07:42:54 -0000 Hi, I think we need to separate between two things:=20 1) Whether an entity supports CLUE or not; and 2) Whether a session between two CLUE-enabled entities are in "clue" or "cl= ueless" state. So, I guess my "fallback" slide should say "fallback to clueless mode", bec= ause both entities are CLUE-enabled. And, when two CLUE-enabled entities establish a session, the initial Offer = will bring them to "clueless" state. Later, when the CLUE channel is establ= ished etc, they will turn into "clue" state. But, I would not like us to use the terminology for indicating whether an e= ntity supports CLUE or not, and to indicate the state of a session between = two CLUE entities. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 2. lokakuuta 2013 6:29 To: clue@ietf.org Subject: Re: [clue] Its not "legacy", its ??? I'm not sure that "CLUEless" is the same as "legacy". "Legacy" seems to imp= ly the absence of the CLUE protocol AND a certain "media stream configurati= on". I think Christer's slides from the design team meeting illustrated thi= s. CLUEless to me suggests that the CLUE channel has been removed (along wi= th the CLUE specific SDP) it doesn't suggest a fall back to a base media se= t. I think this is fine as CLUE and SDP (which does the fallback) are and s= hould be decoupled. So if we are talking about "fallback to legacy" an equivalent would be to s= ay "reverting to a CLUEless session with a basic media configuration". With regards to the definition of CLUEless: the one below seems to focus on= endpoint, you could also have a clueless session. I.e. the endpoint is CLU= E enabled but doesn't use CLUE for the session. Perhaps it would be sufficient to say: "CLUEless: Indicates an absence of t= he CLUE protocol"? Christian On 2/10/2013 4:35 AM, Mary Barnes wrote: > Sure. We can make a definition for the term "clueless", something like: > A SIP endpoint that is not enabled to support the CLUE protocol and=20 > required SDP/RTP extensions. > > We have this concept in XCON and we just use the term non-XCON enabled=20 > client (but we didn't have the convenience of a catch term to use in=20 > place of the expanded term ;) > > Mary. > > > On Tue, Oct 1, 2013 at 1:16 PM, Christer Holmberg=20 > > wrote: > > Hi, > > I am not saying we can't use 'clueless', but I want a term that I > can use and reference outside CLUE, e.g. in 3GPP specifications. > So, we also need some definition text. I can work on that, and > suggest something, as part of the lega... eeeeh... clueless > interworking task. > > Regards, > > Christer > > ---------------------------------------------------------------------= --- > *From:* clue-bounces@ietf.org > [clue-bounces@ietf.org ] on behalf > of Mary Barnes [mary.ietf.barnes@gmail.com > ] > *Sent:* Tuesday, 01 October 2013 7:51 PM > *To:* Robert Hansen > *Cc:* CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > Yeah - I think clueless is a reasonable and compact term to use. > > > On Tue, Oct 1, 2013 at 11:45 AM, Robert Hansen > wrote: > > I am personally very fond of 'CLUEless' :) > > Rob > > > On 01/10/2013 17:22, Paul Kyzivat wrote: > > Mary, > > The minutes are now posted. We did talk about this, briefly. > We decided we didn't want to use the meeting time to > discuss what word > to use - that we could do that on the list. > > I agree with you, I also think "legacy" has the wrong > connotation for > what we mean, so I would like to find a better term. I > have no ideas > that I love, but a couple that I could live with: > "non-clue", "clueless". > > Thanks, > Paul > > On 10/1/13 10:26 AM, Mary Barnes wrote: > > I'm in another meeting so unfortunately cannot attend > today. But, I > would really, really like to get away from the term > "legacy" - the > English language definition of "legacy" is not > correct. CLUE isn't > superseding any functionality of current SIP > endpoints. It's adding > additional functionality. I would much rather select > something like > "non-Clue enabled endpoint". We can shorten if folks > are concerned > about the length of a more appropriate alternative term. > > As an aside, IMHO, the RTCWEB folks using the term > "legacy" is slightly > more appropriate since it's a different architecture > and entirely new > application - i.e., it isn't based on RFC 3261, but > CLUE is, so any > suggestion that it's replacing any current SIP > functionality isn't > correct. > > Regards, > Mary. > > > On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat > > >> wrote: > > You can find Christer's slides for today at: > > > =20 > http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-Tea > m/CLUE_Legacy___1oct13.pptx > > > =20 > LUE_Legacy_1oct13.pptx> > > > See you shortly. > > Paul > _________________________________________________ > clue mailing list > clue@ietf.org > > > https://www.ietf.org/mailman/__listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Oct 2 00:54:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2507E11E8252 for ; Wed, 2 Oct 2013 00:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTc92eWWl2V3 for ; Wed, 2 Oct 2013 00:54:26 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAA11E8192 for ; Wed, 2 Oct 2013 00:54:14 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-e3-524bd1262bef Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.70.25272.621DB425; Wed, 2 Oct 2013 09:54:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 2 Oct 2013 09:54:13 +0200 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJwAJNF4AAB11LgAAgl6UgAAQPZIwAB+AXYAAEnQu0A== Date: Wed, 2 Oct 2013 07:54:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> In-Reply-To: <524B6F63.8060108@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra7aRe8gg/XrZC2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJWx4+ZExoKDAhW3dvxkamBcz9vFyMkhIWAi 8XDmUzYIW0ziwr31QDYXh5DAUUaJ/TvnMoEkhAQWM0pcvqPbxcjBwSZgIdH9TxvEFAHqnX9W E6SCWUBZ4mvDJrBqYQEFifcvdjKD2CICihJ/v+1gBxkpIjCJUeLbkp2MIAkWARWJtS9PgO3l FfCV2LxwNjvE3m2sEs8+7mEBWcApoCPR1+IEUsMIdNv3U2uYIJaJS9x6Mp8J4mYBiSV7zjND 2KISLx//Y4WwFSU+vtrHCFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUWwWkrGzkLTMQtIy C0nLAkaWVYwcxanFSbnpRgabGIExcnDLb4sdjJf/2hxilOZgURLn/fjWOUhIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDYwJ7ecvHU96XOq5FL7w0WfuF/XUb3zoBfgvbeY8nXrvpK1OxyixC Z+OPiRHH28QjL14+wflDZ2P2rYLv738EvJ94zCz/9CuGa6WBvb8kskzdvHokz6vI/NSaMt/8 9xrLO07PM3YumF3sXOx7L8kky3C3S26a+c/DU+dve/i93GtG7Lcd3CobCpRYijMSDbWYi4oT AVmH215fAgAA Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 07:54:54 -0000 Hi, I guess I've missed the "logical capture" concept. If we want to use that, = I think we need to have a clear description and definition of what it means= , and when it is used.=20 Regards, Christer -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com]=20 Sent: 2. lokakuuta 2013 3:57 To: Christer Holmberg Cc: clue@ietf.org Subject: Re: [clue] MCC with CSE Hello Christer, ..snip.. >> [CNG]"Site" information is related to the "CaptureScene" level. So to a = have a "site/scene" level information at the capture level doesn't seem rig= ht. >> To capture the metadata for each "site" in an MCC: >> >> CaptureScene1(Description=3DSiteA,VC1) >> CaptureScene2(Description=3DSiteB,VC2) >> CaptrueScene3(Description=3DSiteC,VC3) >> etc. >> MCC(VC1,VC2,VC3,etc.) > That works fine if the MCU always uses the same VC of each site to create= the MCC. [CNG] VC1 is just a logical representation, it doesn't have to be one of th= e source captures that the MCU received. > > But, if the MCC e.g. contains the active speaker of a site, the CaptureSc= ene descriptions would need to include all VCs that might represent the act= ive speaker of a given site. [CNG] No it doesn't. The VC in this case is only used as a logical entity t= o represent the site. There's no capture encoding. The MCU may wish to adve= rtise all the source captures or produce its own captures based on the sour= ce information. > > So, again, I am not really interested in which VC of each site is used to= create the MCC, I am only interested to know that it represents the active= speaker, and/or the slides, etc. > > Maybe something like: > > CaptureSceneMCU(Description=3DSiteA,SiteB,SiteC, MCC1)=20 > MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker [CNG] I guess you mean MCC1() in the 2nd line? It could work although "Desc= ription" currently doesn't allow multiple values and is an unstructured str= ing so the consumer may not understand that there are essentially multiple = values. > > regards, Christian From Mark.Duckworth@polycom.com Wed Oct 2 06:01:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62011E80FB for ; Wed, 2 Oct 2013 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK7987y8FGti for ; Wed, 2 Oct 2013 06:01:31 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B7A4821F9193 for ; Wed, 2 Oct 2013 05:58:47 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 2 Oct 2013 05:58:47 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 2 Oct 2013 05:58:45 -0700 Thread-Topic: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group Thread-Index: Ac6+8EMT58tZB8AmQzCq5P1UNnQ73AAfmeUA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60345022B@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> <524B4382.60708@alum.mit.edu> In-Reply-To: <524B4382.60708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:01:42 -0000 Thanks Paul. When I was writing this, I was wondering if it would make sense to include = some of the encoding parameters in the CLUE advertisement in addition to ha= ving them in SDP. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, October 01, 2013 5:50 PM > To: clue@ietf.org > Subject: Re: [clue] Ticket #36 removing pixels per second from framework > encoding and encoding group >=20 > Mark, >=20 > On 9/30/13 1:18 PM, Duckworth, Mark wrote: >=20 > > I propose keeping the first three paragraphs as is. And change the > > rest to something like this: > > > > =3D=3D=3D=3D begin proposed=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > Individual Encoding parameters are represented in SDP [RFC4566], > > not in CLUE messages. For example, for a video encoding using H.26x > > compression technologies, this can include parameters such as: > > > > *Maximum bandwidth; > > > > *Maximum picture size in pixels; > > > > *Maxmimum number of pixels to be processed per second; > > > > The bandwidth parameter is the only one that specifically relates to a > > CLUE Advertisement, as it can be further constrained by the maximum > > group bandwidth in an Encoding Group. > > > > =3D=3D=3D=3D end proposed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The above is dependent on encodings being expressed only in SDP. > That is still up in the air. Rob is in the process of analyzing the pros/= cons of > having them SDP and having them in the Advertisement. >=20 > I think a final resolution of *this* will have to wait until that is deci= ded. But > you can still do this for now, and change later if need be. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From coverdale@sympatico.ca Wed Oct 2 06:39:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD2521F99BD for ; Wed, 2 Oct 2013 06:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4J0C0AOEq6Z for ; Wed, 2 Oct 2013 06:38:56 -0700 (PDT) Received: from blu0-omc1-s26.blu0.hotmail.com (blu0-omc1-s26.blu0.hotmail.com [65.55.116.37]) by ietfa.amsl.com (Postfix) with ESMTP id DC3EA21F9A59 for ; Wed, 2 Oct 2013 06:35:07 -0700 (PDT) Received: from BLU0-SMTP14 ([65.55.116.7]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 06:35:07 -0700 X-TMN: [qxyd7QB36yxmN/arUHQyrLgZ3NYkt3Lu] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.36.183]) by BLU0-SMTP14.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 06:35:03 -0700 From: Paul Coverdale To: References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> In-Reply-To: <524B414C.2030406@alum.mit.edu> Date: Wed, 2 Oct 2013 09:35:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unAAhI+uA Content-Language: en-us X-OriginalArrivalTime: 02 Oct 2013 13:35:04.0155 (UTC) FILETIME=[33815AB0:01CEBF74] Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:39:07 -0000 I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>> > wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Oct 2 06:58:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3607621F8F6D for ; Wed, 2 Oct 2013 06:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.466 X-Spam-Level: X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeyHgMKZy8BH for ; Wed, 2 Oct 2013 06:58:37 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0BE21F9D7D for ; Wed, 2 Oct 2013 06:56:55 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id 1so564319qee.28 for ; Wed, 02 Oct 2013 06:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=71piBYNgX1h3p5Yx4kdsmlPazoKucMa3wXbLbvCbqoo=; b=m5Yb/HYZP27kP+Ef1l0wDDlb7dmMblb1ThctT5v5oI+8GIqMFyMk+sxRlXgMmeSIsq Pp5IlJLqkZWKXpHXTFJrZB/ygbbP36twihov/F2UNI/ST8QD76aX0fEotG3KI6IvBVE+ +p5odyjblL2F38MpyNJpgS/f7rwXVUJSWwVk4tepFmx9nm9p9b8fNkPcaj51ORCQJwEb uqfOWU+H6NR1pHDt7FAQ2NCaxuZ66jkGW68DNjJSPCnXz53EqmEO/ZdGRO06qwMe0dNV J+xK7/fdzKU+MY6ExPAecj2SYYdn6eIUoE2XhCFIWS2zSrrIxcjGN1vCxIWeMGOYF22k K8Xg== MIME-Version: 1.0 X-Received: by 10.224.34.74 with SMTP id k10mr3616111qad.63.1380722214309; Wed, 02 Oct 2013 06:56:54 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 2 Oct 2013 06:56:54 -0700 (PDT) In-Reply-To: References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> Date: Wed, 2 Oct 2013 08:56:54 -0500 Message-ID: From: Mary Barnes To: Paul Coverdale Content-Type: multipart/alternative; boundary=001a11c2cd781e144504e7c27136 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 13:58:45 -0000 --001a11c2cd781e144504e7c27136 Content-Type: text/plain; charset=ISO-8859-1 It is a fine line. I personally have a preference for "non-CLUE enabled". I really don't think we'll be using that in too many places in the documents that it's too much typing. If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship them out of the WG and then just do a global change. As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale wrote: > I thought the proposal of "clueless' was just a joke when I first saw it, > but apparently not. > > I think this term will just invite ridicule. It's a bit of a mouthful, but > I > would suggest "non-CLUE" equipped". But if you insist on using "clueless", > at least hyphenate it (clue-less). > > ...Paul > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >Paul Kyzivat > >Sent: Tuesday, October 01, 2013 5:40 PM > >To: clue@ietf.org > >Subject: Re: [clue] Its not "legacy", its ??? > > > >On 10/1/13 12:45 PM, Robert Hansen wrote: > >> I am personally very fond of 'CLUEless' :) > > > >One of the reasons I liked the name "clue" for the wg was because it > >gave us an excuse to use "clueless" and "clueful". However they do have > >the feel of "informal" usage - a bit odd for formal use. (But I can get > >over that.) > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 01/10/2013 17:22, Paul Kyzivat wrote: > >>> Mary, > >>> > >>> The minutes are now posted. We did talk about this, briefly. > >>> We decided we didn't want to use the meeting time to discuss what > >>> word to use - that we could do that on the list. > >>> > >>> I agree with you, I also think "legacy" has the wrong connotation for > >>> what we mean, so I would like to find a better term. I have no ideas > >>> that I love, but a couple that I could live with: "non-clue", > >"clueless". > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/1/13 10:26 AM, Mary Barnes wrote: > >>>> I'm in another meeting so unfortunately cannot attend today. But, I > >>>> would really, really like to get away from the term "legacy" - the > >>>> English language definition of "legacy" is not correct. CLUE isn't > >>>> superseding any functionality of current SIP endpoints. It's adding > >>>> additional functionality. I would much rather select something like > >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned > >>>> about the length of a more appropriate alternative term. > >>>> > >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is > >>>> slightly more appropriate since it's a different architecture and > >>>> entirely new application - i.e., it isn't based on RFC 3261, but > >>>> CLUE is, so any suggestion that it's replacing any current SIP > >>>> functionality isn't correct. > >>>> > >>>> Regards, > >>>> Mary. > >>>> > >>>> > >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> > wrote: > >>>> > >>>> You can find Christer's slides for today at: > >>>> > >>>> > >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T > >>>> eam/CLUE_Legacy___1oct13.pptx > >>>> > >>>> > >>>> > >>>> >>>> /CLUE_Legacy_1oct13.pptx> > >>>> > >>>> > >>>> > >>>> See you shortly. > >>>> > >>>> Paul > >>>> _________________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a11c2cd781e144504e7c27136 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It is a fine line. =A0I personally have a preference for &= quot;non-CLUE enabled". =A0 I really don't think we'll be usin= g that in too many places in the documents that it's too much typing. = =A0If someone thinks that's the case, perhaps we use "clueless&quo= t; in the docs until we're ready to ship them out of the WG and then ju= st do a global change. =A0As I've said before for XCON, we do use the t= erm "non-XCON enabled" which I think has the right semantics and = really isn't too much of a mouthful to say either.

Mary.=A0


On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> wrote:
I thought the proposal of "clueless'= ; was just a joke when I first saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, = but I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul

>-----Original Message-----
>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>
>On 10/1/13 12:45 PM, Robe= rt Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discu= ss what
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>> =A0 =A0 =A0Thanks,
>>> =A0 =A0 =A0Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend = today. =A0But, I
>>>> would really, really like to get away from the term "= legacy" - =A0the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. = =A0It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint". =A0 We can shorten = if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different archi= tecture and
>>>> entirely new application - i.e., it isn't based on RFC= 3261, but
>>>> CLUE is, so any suggestion that it's replacing any cur= rent SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyziv= at@alum.mit.edu>> wrote:
>>>>
>>>> =A0 =A0 You can find Christer's slides for today at: >>>>
>>>>
>>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T=
>>>> eam/CLUE_Legacy___1oct13.pptx
>>>>
>>>>
>>>>
>>>> <http://trac.tools.ietf.org/wg/c= lue/trac/attachment/wiki/Design-Team
>>>> /CLUE_Legacy= _1oct13.pptx>
>>>>
>>>>
>>>>
>>>> =A0 =A0 See you shortly.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
>>>> =A0 =A0 _________________________________________________<= br> >>>> =A0 =A0 clue mailing list
>>>> =A0 =A0 clue@ietf.org= <mailto:clue@ietf.org>
>>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue >>>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue&g= t;
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--001a11c2cd781e144504e7c27136-- From keith.drage@alcatel-lucent.com Wed Oct 2 07:14:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF07E21F9978 for ; Wed, 2 Oct 2013 07:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFyjJvzorQ0o for ; Wed, 2 Oct 2013 07:13:55 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB0D721F9F3D for ; Wed, 2 Oct 2013 07:12:44 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r92ECYvb023675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Oct 2013 09:12:36 -0500 (CDT) 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 r92ECXMd010234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 16:12:34 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 2 Oct 2013 16:12:34 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Paul Coverdale Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unAAhI+uA///l8wD//9rPkA== Date: Wed, 2 Oct 2013 14:12:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> In-Reply-To: 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0AE8A1FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:14:07 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0AE8A1FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we h= ave is something where CLUE does not exist, not the creation of some other = concept of a "non-CLUE" to complement a "CLUE". You want to apply the negat= ion to the "enabled" which is something like "disabled", "unenabled" or wha= tever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_949EF20990823C4C85C18D59AA11AD8B0AE8A1FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just to add a pedantic point, I am not= sure what a “non-CLUE” is. What we have is something where CLU= E does not exist, not the creation of some other concept of a “non-CLUE” to complement a “C= LUE”. You want to apply the negation to the “enabled” whi= ch is something like “disabled”, “unenabled” or wha= tever.

 

Keith

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

It is a fine line.  I personally have a preference for "n= on-CLUE enabled".   I really don't think we'll be using that in t= oo many places in the documents that it's too much typing.  If someone thinks that's the case, perhaps we use "= ;clueless" in the docs until we're ready to ship them out of the WG an= d then just do a global change.  As I've said before for XCON, we do u= se the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either.

 

Mary. 

 

On Wed, Oct= 2, 2013 at 8:35 AM, Paul Cov= erdale <cove= rdale@sympatico.ca> wrote:

I thought the proposal of "clueless' was just a joke when I fi= rst saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyziv= at@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.o= rg <mailto:clue@ietf.org> >>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

 

--_000_949EF20990823C4C85C18D59AA11AD8B0AE8A1FR712WXCHMBA11zeu_-- From mary.ietf.barnes@gmail.com Wed Oct 2 07:18:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED88D21F86BE for ; Wed, 2 Oct 2013 07:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.533 X-Spam-Level: X-Spam-Status: No, score=-101.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1h-TakNYl3m for ; Wed, 2 Oct 2013 07:18:06 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 26A0121F995B for ; Wed, 2 Oct 2013 07:17:15 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so4355887qaq.3 for ; Wed, 02 Oct 2013 07:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CZvwe692aNrvo6yxvwMm+qIPEBWRckOrkda/i8N/Diw=; b=0tvGoMdh6rQK/QcjlGWkYgk5t6POw3LvOd4SIHNRjR6owimrcxB12iQ9YyB07EoitK FeQQquduN3B5hznAAbEiRuDsy1OtYzD4WoNCtTWGY80CxnZ7j+qOgcfkL1srOc4gkHGe FtgvAYAOouXb+js5SaEbHuU8C2XDzmeTRQqXiOsUMMVdOEPFYsy1VyCIlkTJTXY1lP81 IxdDBnodbbKVLmy164pcTP8r/5D2ODIEIsP1bKRwHEhds7QblHL6tOZLo7T0sznbEpHQ b9/J3K1uh8H0pOIEm8QIl50j5eq/6L7eL7b8OZC9HheeNAyg4/oxt5uwa4dj5bogyh5m LrTw== MIME-Version: 1.0 X-Received: by 10.49.35.106 with SMTP id g10mr3065938qej.35.1380723433391; Wed, 02 Oct 2013 07:17:13 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 2 Oct 2013 07:17:13 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 2 Oct 2013 09:17:13 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=047d7b6766f8c80a1704e7c2b929 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:18:14 -0000 --047d7b6766f8c80a1704e7c2b929 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "non-CLUE enabled" means the endpoint does not support the CLUE protocol (at all) or the endpoint is not using the CLUE protocol for whatever reason (e.g., fallback case) I think the "non-CLUE" is more in line with the original implication of the term "legacy". Mary . On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > **** > > Just to add a pedantic point, I am not sure what a =93non-CLUE=94 is. Wha= t we > have is something where CLUE does not exist, not the creation of some oth= er > concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to apply= the > negation to the =93enabled=94 which is something like =93disabled=94, =93= unenabled=94 > or whatever.**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 02 October 2013 14:57 > *To:* Paul Coverdale > *Cc:* CLUE > > *Subject:* Re: [clue] Its not "legacy", its ??? > **** > > ** ** > > It is a fine line. I personally have a preference for "non-CLUE enabled"= . > I really don't think we'll be using that in too many places in the > documents that it's too much typing. If someone thinks that's the case, > perhaps we use "clueless" in the docs until we're ready to ship them out = of > the WG and then just do a global change. As I've said before for XCON, w= e > do use the term "non-XCON enabled" which I think has the right semantics > and really isn't too much of a mouthful to say either.**** > > ** ** > > Mary. **** > > ** ** > > On Wed, **Oct 2, 2013** at **8:35 AM**, Paul Coverdale < > coverdale@sympatico.ca> wrote:**** > > I thought the proposal of "clueless' was just a joke when I first saw it, > but apparently not. > > I think this term will just invite ridicule. It's a bit of a mouthful, bu= t > I > would suggest "non-CLUE" equipped". But if you insist on using "clueless"= , > at least hyphenate it (clue-less). > > ...Paul**** > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of*= * > ** > > >Paul Kyzivat > >Sent: Tuesday, **October 01, 2013** **5:40 PM** > >To: clue@ietf.org > >Subject: Re: [clue] Its not "legacy", its ??? > >**** > > >On 10/1/13 12:45 PM, Robert Hansen wrote: > >> I am personally very fond of 'CLUEless' :) > > > >One of the reasons I liked the name "clue" for the wg was because it > >gave us an excuse to use "clueless" and "clueful". However they do have > >the feel of "informal" usage - a bit odd for formal use. (But I can get > >over that.) > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 01/10/2013 17:22, Paul Kyzivat wrote: > >>> Mary, > >>> > >>> The minutes are now posted. We did talk about this, briefly. > >>> We decided we didn't want to use the meeting time to discuss what > >>> word to use - that we could do that on the list. > >>> > >>> I agree with you, I also think "legacy" has the wrong connotation for > >>> what we mean, so I would like to find a better term. I have no ideas > >>> that I love, but a couple that I could live with: "non-clue", > >"clueless". > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/1/13 10:26 AM, Mary Barnes wrote: > >>>> I'm in another meeting so unfortunately cannot attend today. But, I > >>>> would really, really like to get away from the term "legacy" - the > >>>> English language definition of "legacy" is not correct. CLUE isn't > >>>> superseding any functionality of current SIP endpoints. It's adding > >>>> additional functionality. I would much rather select something like > >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned > >>>> about the length of a more appropriate alternative term. > >>>> > >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is > >>>> slightly more appropriate since it's a different architecture and > >>>> entirely new application - i.e., it isn't based on RFC 3261, but > >>>> CLUE is, so any suggestion that it's replacing any current SIP > >>>> functionality isn't correct. > >>>> > >>>> Regards, > >>>> Mary. > >>>> > >>>> > >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> > wrote: > >>>> > >>>> You can find Christer's slides for today at: > >>>> > >>>>**** > > >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T > >>>> eam/CLUE_Legacy___1oct13.pptx > >>>> > >>>> > >>>> > >>>> *** > > >>>> /CLUE_Legacy_1oct13.pptx> > >>>> > >>>> > >>>> > >>>> See you shortly. > >>>> > >>>> Paul > >>>> _________________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --047d7b6766f8c80a1704e7c2b929 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
"non-CLUE enabled" means the endpoint does not s= upport the CLUE protocol (at all) or the endpoint is not using the CLUE pro= tocol for whatever reason (e.g., fallback case)

I think = the "non-CLUE" is more in line with the original implication of t= he term "legacy". =A0

Mary .
--047d7b6766f8c80a1704e7c2b929-- From coverdale@sympatico.ca Wed Oct 2 07:22:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273DB21F90E5 for ; Wed, 2 Oct 2013 07:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6F-foRA+9Ql for ; Wed, 2 Oct 2013 07:22:00 -0700 (PDT) Received: from blu0-omc1-s16.blu0.hotmail.com (blu0-omc1-s16.blu0.hotmail.com [65.55.116.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2366921F90CC for ; Wed, 2 Oct 2013 07:21:51 -0700 (PDT) Received: from BLU0-SMTP48 ([65.55.116.7]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 07:21:50 -0700 X-TMN: [xO+Y36yCGviWNetUIhaN/7OH7i3uzGxw] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.36.183]) by BLU0-SMTP48.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 07:21:47 -0700 From: Paul Coverdale To: "'DRAGE, Keith \(Keith\)'" References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 2 Oct 2013 10:21:43 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CEBF59.32657EB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unAAhI+uA///l8wD//9rPkP//tAiA Content-Language: en-us X-OriginalArrivalTime: 02 Oct 2013 14:21:48.0343 (UTC) FILETIME=[BAEE7C70:01CEBF7A] Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:22:12 -0000 ------=_NextPart_000_0019_01CEBF59.32657EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we want to negate, not whether it is enabled or not. If we negate "enabled", using "disabled' or whatever, it would imply some other type of system which has CLUE capability, but for some reason doesn't want to use it. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:13 AM To: Mary Barnes; Paul Coverdale Cc: CLUE Subject: RE: [clue] Its not "legacy", its ??? Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we have is something where CLUE does not exist, not the creation of some other concept of a "non-CLUE" to complement a "CLUE". You want to apply the negation to the "enabled" which is something like "disabled", "unenabled" or whatever. Keith _____ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". I really don't think we'll be using that in too many places in the documents that it's too much typing. If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship them out of the WG and then just do a global change. As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>> > wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0019_01CEBF59.32657EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure I agree with your reasoning, Keith. It’s the = “CLUE” part we want to negate, not whether it is enabled or = not. If we negate “enabled”, using “disabled’ or = whatever, it would imply some other type of system which has CLUE = capability, but for some reason doesn’t want to use = it.

 

 

...Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] =
Sent: Wednesday, October 02, 2013 10:13 AM
To: Mary = Barnes; Paul Coverdale
Cc: CLUE
Subject: RE: [clue] = Its not "legacy", its ???

 

Ju= st to add a pedantic point, I am not sure what a “non-CLUE” = is. What we have is something where CLUE does not exist, not the = creation of some other concept of a “non-CLUE” to complement = a “CLUE”. You want to apply the negation to the = “enabled” which is something like “disabled”, = “unenabled” or whatever.

 

Ke= ith

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Mary Barnes
Sent: 02 October 2013 = 14:57
To: Paul Coverdale
Cc: CLUE
Subject: = Re: [clue] Its not "legacy", its = ???

 

It is a fine line.  I personally have a preference for = "non-CLUE enabled".   I really don't think we'll be using = that in too many places in the documents that it's too much typing. =  If someone thinks that's the case, perhaps we use = "clueless" in the docs until we're ready to ship them out of = the WG and then just do a global change.  As I've said before for = XCON, we do use the term "non-XCON enabled" which I think has = the right semantics and really isn't too much of a mouthful to say = either.

 

Mary. 

 

On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> = wrote:

I = thought the proposal of "clueless' was just a joke when I first saw = it,
but apparently not.

I think this term will just invite = ridicule. It's a bit of a mouthful, but I
would suggest = "non-CLUE" equipped". But if you insist on using = "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original = Message-----
>From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 = 5:40 PM
>To: clue@ietf.org
>Subject: Re: = [clue] Its not "legacy", its = ???
>

>On 10/1/13 12:45 PM, Robert = Hansen wrote:
>> I am personally very fond of 'CLUEless' = :)
>
>One of the reasons I liked the name "clue" = for the wg was because it
>gave us an excuse to use = "clueless" and "clueful". However they do = have
>the feel of "informal" usage - a bit odd for = formal use. (But I can get
>over that.)
>
>   =     Thanks,
>       = Paul
>
>> Rob
>>
>> On 01/10/2013 = 17:22, Paul Kyzivat wrote:
>>> = Mary,
>>>
>>> The minutes are now posted. We did = talk about this, briefly.
>>> We decided we didn't want to = use the meeting time to discuss what
>>> word to use - that = we could do that on the list.
>>>
>>> I agree = with you, I also think "legacy" has the wrong connotation = for
>>> what we mean, so I would like to find a better term. = I have no ideas
>>> that I love, but a couple that I could = live with: = "non-clue",
>"clueless".
>>>
>= ;>>      Thanks,
>>>     =  Paul
>>>
>>> On 10/1/13 10:26 AM, Mary = Barnes wrote:
>>>> I'm in another meeting so = unfortunately cannot attend today.  But, I
>>>> = would really, really like to get away from the term "legacy" - =  the
>>>> English language definition of = "legacy" is not correct. CLUE isn't
>>>> = superseding any functionality of current SIP endpoints.  It's = adding
>>>> additional functionality. I would much rather = select something like
>>>> "non-Clue enabled = endpoint".   We can shorten if folks are = concerned
>>>> about the length of a more appropriate = alternative term.
>>>>
>>>> As an aside, = IMHO, the RTCWEB folks using the term "legacy" = is
>>>> slightly more appropriate since it's a different = architecture and
>>>> entirely new application - i.e., it = isn't based on RFC 3261, but
>>>> CLUE is, so any = suggestion that it's replacing any current SIP
>>>> = functionality isn't correct.
>>>>
>>>> = Regards,
>>>> = Mary.
>>>>
>>>>
>>>> On = Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>&g= t;>> <mailto:pkyzivat@alum.mit.edu>> = wrote:
>>>>
>>>>     You can = find Christer's slides for today = at:
>>>>
>>>>

>>>> = /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
&= gt;>>>
>>>>     See you = shortly.
>>>>
>>>>       =        Paul
>>>>     = _________________________________________________
>>>> =     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>> =     https://www.ietf.org/mailman/__listinfo/clue
>= ;>>>     <https://www.ietf.org/mailman/listinfo/clue>
&= gt;>>>
>>>>
>>>
>>> = _______________________________________________
>>> clue = mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>> = _______________________________________________
>> clue mailing = list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>
>_______________________________________________
>= ;clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_= ______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

<= /html> ------=_NextPart_000_0019_01CEBF59.32657EB0-- From christer.holmberg@ericsson.com Wed Oct 2 07:46:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B860621F9C99 for ; Wed, 2 Oct 2013 07:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.64 X-Spam-Level: X-Spam-Status: No, score=-5.64 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO8Knl6qZZPk for ; Wed, 2 Oct 2013 07:46:19 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB0821F996A for ; Wed, 2 Oct 2013 07:44:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-e1-524c313b2016 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 69.38.16099.B313C425; Wed, 2 Oct 2013 16:44:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 2 Oct 2013 16:44:11 +0200 From: Christer Holmberg To: Paul Coverdale , "'DRAGE, Keith (Keith)'" Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOvsKWUVs+qhhkEE2in1P/xTqM7pnf7C+AgABSdQCAAQqxAIAABh8AgAAEYACAAAKPgIAAJvF4gAAA4L0= Date: Wed, 2 Oct 2013 14:44:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B244C@ESESSMB209.ericsson.se> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4B244CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvra6NoU+QwaU2dov9py4zW8x5+YbR 4mnjWUYHZo/WZ3tZPZYs+cnksbosgDmKyyYlNSezLLVI3y6BK2PX7dOMBc0bGSvuL/7L0sC4 cgZjFyMnh4SAiUTj9J1sELaYxIV764FsLg4hgcOMElf6OlkgnMWMEnuXfgHKcHCwCVhIdP/T BmkQEciQ+DF1EjuIzSwgJXHh2l1mkBJhAV2JLdsFIUr0JO7+nsgKYSdJfJx5EMxmEVCReLF+ O9heXgFfiSvPrzNBrDrNLNF7aRfYTE4Ba4lnX6czg9iMQMd9P7WGCWKXuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1YIW1Hi46t9jBD1+RLrjkL08goISpyc+YRlAqPoLCSjZiEpm4WkDCJuIPH+ 3HxmCFtbYtnC11C2vsTGL2cZIWxrid72PezIahYwcqxiZM9NzMxJLzfcxAiMv4NbfuvuYDx1 TuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGC0Xvj47Xfjbn19XFX4n PivZ9P3V3zudk1TEd6Wd/FHgsESqbMuus4dOLDNKWe74xnPzr19+74oUv1x6s/BjTMuWhomC e+6ELyxynaMof7w25MS1HbePP5l3je2kefoWu7VpWRdyF700ZWY6NTnyw4SVupH6B0uVxM/s 1/VeODFKsl5Vnf3YFVsXJZbijERDLeai4kQACrUxSo0CAAA= Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:46:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4B244CESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I agree that "non-CLUE enabled" refers to an entity that doesn't support CL= UE, or for whatever reason does not want to use CLUE. But, still, even when a session is established between two CLUE enabled cli= ents, the initial Offer/Answer will be for a "non-CLUE session" - in order = to interwork with non-CLUE enabled devices. Then, if both endpoints are CLU= E enabled, the data channel will be established, CLUE messages will be sent= , and one or more CLUE specific Offer/Answers will be sent. Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Cover= dale [coverdale@sympatico.ca] Sent: Wednesday, 02 October 2013 5:21 PM To: 'DRAGE, Keith (Keith)' Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? I=92m not sure I agree with your reasoning, Keith. It=92s the =93CLUE=94 pa= rt we want to negate, not whether it is enabled or not. If we negate =93ena= bled=94, using =93disabled=92 or whatever, it would imply some other type o= f system which has CLUE capability, but for some reason doesn=92t want to u= se it. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:13 AM To: Mary Barnes; Paul Coverdale Cc: CLUE Subject: RE: [clue] Its not "legacy", its ??? Just to add a pedantic point, I am not sure what a =93non-CLUE=94 is. What = we have is something where CLUE does not exist, not the creation of some ot= her concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to app= ly the negation to the =93enabled=94 which is something like =93disabled=94= , =93unenabled=94 or whatever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C4B244CESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <964D0082AC36CE49B086B7FC5DAEBD87@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

I agree that "non-CLUE enabled" refers to an entity that doesn= 't support CLUE, or for whatever reason does not want to use CLUE.

 

But, still, even when a session is established between two CLUE enabled = clients, the initial Offer/Answer will be for a "non-CLUE session"= ; - in order to interwork with non-CLUE enabled devices. Then, if both endp= oints are CLUE enabled, the data channel will be established, CLUE messages will be sent, and one or more CLUE specific = Offer/Answers will be sent.

 

Regards,

 

Christer

 

From: clue-bounces@ietf.org [clue-bounces= @ietf.org] on behalf of Paul Coverdale [coverdale@sympatico.ca]
Sent: Wednesday, 02 October 2013 5:21 PM
To: 'DRAGE, Keith (Keith)'
Cc: 'CLUE'
Subject: Re: [clue] Its not "legacy", its ???

I=92m not su= re I agree with your reasoning, Keith. It=92s the =93CLUE=94 part we want t= o negate, not whether it is enabled or not. If we negate =93enabled=94, using =93disabled=92 or whatever, it would imply some other type of system= which has CLUE capability, but for some reason doesn=92t want to use it.

 

 

...Paul

 

From: DRAG= E, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, October 02, 2013 10:13 AM
To: Mary Barnes; Paul Coverdale
Cc: CLUE
Subject: RE: [clue] Its not "legacy", its ???

 

Just to add= a pedantic point, I am not sure what a =93non-CLUE=94 is. What we have is = something where CLUE does not exist, not the creation of some other concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to = apply the negation to the =93enabled=94 which is something like =93disabled= =94, =93unenabled=94 or whatever.

 

Keith

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

 

It is a fine line.  I pers= onally have a preference for "non-CLUE enabled".   I really = don't think we'll be using that in too many places in the documents that it= 's too much typing.  If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship = them out of the WG and then just do a global change.  As I've said bef= ore for XCON, we do use the term "non-XCON enabled" which I think= has the right semantics and really isn't too much of a mouthful to say either.

 

Mary. 

=  

On Wed, Oct 2, 2013 at 8:35 AM,= Paul Coverdale <coverdale@sympatico.ca> wrote:

I thought the proposal of "= ;clueless' was just a joke when I first saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original Message-----
>From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert= Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1= oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4B244CESESSMB209erics_-- From keith.drage@alcatel-lucent.com Wed Oct 2 07:47:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029A621F9C00 for ; Wed, 2 Oct 2013 07:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-nIDt5SUq1u for ; Wed, 2 Oct 2013 07:47:27 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id A061521F9C20 for ; Wed, 2 Oct 2013 07:45:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r92EjDx8024089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Oct 2013 09:45:14 -0500 (CDT) 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 r92EjBHs004183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 16:45:11 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 2 Oct 2013 16:45:11 +0200 From: "DRAGE, Keith (Keith)" To: Paul Coverdale Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unAAhI+uA///l8wD//9rPkP//tAiA//9isYA= Date: Wed, 2 Oct 2013 14:45:10 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0AE963@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0AE963FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:47:42 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0AE963FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is just saying the negative chosen is the wrong one. "CLUE unsupported" "CLUE inhibited" "CLUE disallowed" "CLUE frustrated" Keith ________________________________ From: Paul Coverdale [mailto:coverdale@sympatico.ca] Sent: 02 October 2013 15:22 To: DRAGE, Keith (Keith) Cc: 'CLUE' Subject: RE: [clue] Its not "legacy", its ??? I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we wa= nt to negate, not whether it is enabled or not. If we negate "enabled", usi= ng "disabled' or whatever, it would imply some other type of system which h= as CLUE capability, but for some reason doesn't want to use it. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:13 AM To: Mary Barnes; Paul Coverdale Cc: CLUE Subject: RE: [clue] Its not "legacy", its ??? Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we h= ave is something where CLUE does not exist, not the creation of some other = concept of a "non-CLUE" to complement a "CLUE". You want to apply the negat= ion to the "enabled" which is something like "disabled", "unenabled" or wha= tever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_949EF20990823C4C85C18D59AA11AD8B0AE963FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is just saying the negative chose= n is the wrong one.

 

“CLUE unsupported”

 

“CLUE inhibited”

 

“CLUE disallowed”

 

“CLUE frustrated”

 

Keith

 

From: Paul Coverdale [mailto:coverdale@sympatico.ca]
Sent: 02 October 2013 15:22<= br> To: DRAGE, Keith (Keith)
Cc: 'CLUE'
Subject: RE: [clue] Its not = "legacy", its ???

 

= I’m not sure I agree with your reasoning, Keith. It’s th= e “CLUE” part we want to negate, not whether it is enabled or not. If we negate “enabled”, using “disabled’ o= r whatever, it would imply some other type of system which has CLUE capabil= ity, but for some reason doesn’t want to use it.

=  

=  

= ...Paul

=  

From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, October 02, 2013 10:13 AM
To: Mary Barnes; Paul Coverd= ale
Cc: CLUE
Subject: RE: [clue] Its not = "legacy", its ???

 

Just to add a pedantic point, I am not= sure what a “non-CLUE” is. What we have is something where CLU= E does not exist, not the creation of some other concept of a “non-CLUE” to complement a “C= LUE”. You want to apply the negation to the “enabled” whi= ch is something like “disabled”, “unenabled” or wha= tever.

 

Keith

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

It is a fine line.  I personally have a preference for "n= on-CLUE enabled".   I really don't think we'll be using that in t= oo many places in the documents that it's too much typing.  If someone thinks that's the case, perhaps we use "= ;clueless" in the docs until we're ready to ship them out of the WG an= d then just do a global change.  As I've said before for XCON, we do u= se the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either.

 

Mary. 

 

On Wed, Oct= 2, 2013 at 8:35 AM, Paul Cov= erdale <cove= rdale@sympatico.ca> wrote:

I thought the proposal of "clueless' was just a joke when I fi= rst saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyziv= at@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.o= rg <mailto:clue@ietf.org> >>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

 

--_000_949EF20990823C4C85C18D59AA11AD8B0AE963FR712WXCHMBA11zeu_-- From keith.drage@alcatel-lucent.com Wed Oct 2 07:47:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE7221F9C47 for ; Wed, 2 Oct 2013 07:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD9XZV2TCLrb for ; Wed, 2 Oct 2013 07:47:39 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0196A21F9C28 for ; Wed, 2 Oct 2013 07:45:19 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r92EjDwV024087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 2 Oct 2013 09:45:14 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r92EjADg007420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Oct 2013 16:45:10 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 2 Oct 2013 16:45:10 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOv3oWJ1Ix+kZPRoO+ExTufi0unJnhdbpQ Date: Wed, 2 Oct 2013 14:45:09 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: 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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0AE960FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:47:57 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0AE960FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you don't have a telephone, you don't suddenly have a "non-telephone", o= n which you make your "non-calls". You need to apply the negation to the right word, and it is not CLUE that i= s subject to the negation. Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 02 October 2013 15:17 To: DRAGE, Keith (Keith) Cc: Paul Coverdale; CLUE Subject: Re: [clue] Its not "legacy", its ??? "non-CLUE enabled" means the endpoint does not support the CLUE protocol (a= t all) or the endpoint is not using the CLUE protocol for whatever reason (= e.g., fallback case) I think the "non-CLUE" is more in line with the original implication of the= term "legacy". Mary . On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) > wrote: Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we h= ave is something where CLUE does not exist, not the creation of some other = concept of a "non-CLUE" to complement a "CLUE". You want to apply the negat= ion to the "enabled" which is something like "disabled", "unenabled" or wha= tever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_949EF20990823C4C85C18D59AA11AD8B0AE960FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you don’t have a telephone, y= ou don’t suddenly have a “non-telephone”, on which you ma= ke your “non-calls”.

 

You need to apply the negation to the = right word, and it is not CLUE that is subject to the negation.<= /span>

 

Keith

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 02 October 2013 15:17<= br> To: DRAGE, Keith (Keith)
Cc: Paul Coverdale; CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

"non-CLUE enabled" means the endpoint does not support th= e CLUE protocol (at all) or the endpoint is not using the CLUE protocol for= whatever reason (e.g., fallback case)

 

I think the "non-CLUE" is more in line with the original = implication of the term "legacy".  =

 

Mary .

 

On Wed, Oct= 2, 2013 at 9:12 AM, DRAGE, K= eith (Keith) <keith.drage@alcatel-lucent.com> wrote:=

Just to add a pedantic point, I am not sure what a “non-C= LUE” is. What we have is something where CLUE does not exist, not the creation of some othe= r concept of a “non-CLUE” to complement a “CLUE”. Y= ou want to apply the negation to the “enabled” which is somethi= ng like “disabled”, “unenabled” or whatever.=

 

Keith

 

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Tahoma"> clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
Cc: CLUE<= /o:p>


Subject: Re: [clue] Its not = "legacy", its ???

 

It is a fine line.  I personally have a preference for "= non-CLUE enabled".   I really don't think we'll be using that in too many places in the documents that it's too much typing.  = If someone thinks that's the case, perhaps we use "clueless" in t= he docs until we're ready to ship them out of the WG and then just do a glo= bal change.  As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right sema= ntics and really isn't too much of a mouthful to say either.

 

Mary. 

 

On Wed, Oct= 2, 2013 at 8:35 AM, Paul Cov= erdale <cove= rdale@sympatico.ca> wrote:

I thought the proposal of "clueless' was just a joke when I f= irst saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original Message-----
>From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

 

 

--_000_949EF20990823C4C85C18D59AA11AD8B0AE960FR712WXCHMBA11zeu_-- From mary.ietf.barnes@gmail.com Wed Oct 2 07:54:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532C621F8F2E for ; Wed, 2 Oct 2013 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUV2P3smuZuy for ; Wed, 2 Oct 2013 07:54:10 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7C621F898A for ; Wed, 2 Oct 2013 07:52:04 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so628794qeu.33 for ; Wed, 02 Oct 2013 07:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=twrSbkJGDcp7CvYlHvB41b7Di30jecsDAoaIlqtcjyE=; b=Zt43GjZasi/gBBn79hTT2uQMbENj101ydP0/VatkxLs4FVD4j70wf3FDnqE0M0WpV/ 4psiKb5faTwXnXX9oUqJVKa9K1iNMlsH64tEo9O7Y5io3qYkHTMQguoQH8hm7oe7RfLY aV4OV5WvTxA09hB636kGzAf5r0+zA8447idybKP0Ed0cIGv3y63+xFTLVBZJJICqgZgD zrtmyBzOXHmWNHKyU9Boh13vgGHHgN19/ViiRmWCgV01EMyaKr7XiG+Yw2QD6gvi4mXC rURXrz9OW9Bpx/jMYG1t/dcSXmDfqe5vazz+c011oWWQyLfFuwLR8ajp5QuEHRdvtJeD ywzw== MIME-Version: 1.0 X-Received: by 10.224.123.208 with SMTP id q16mr4098345qar.12.1380725523102; Wed, 02 Oct 2013 07:52:03 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 2 Oct 2013 07:52:02 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 2 Oct 2013 09:52:02 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=047d7bdc8e065647fa04e7c33654 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:54:20 -0000 --047d7bdc8e065647fa04e7c33654 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 2, 2013 at 9:45 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > **** > > If you don=92t have a telephone, you don=92t suddenly have a =93non-telep= hone=94, > on which you make your =93non-calls=94. > [MB] CLUE isn't an endpoint - it's functionality supported by an endpoint. So, non-CLUE means you don't support the CLUE protocol or related processing to handle that protocol. [/MB] > **** > > ** ** > > You need to apply the negation to the right word, and it is not CLUE that > is subject to the negation.**** > > ** ** > > Keith**** > > ** ** > ------------------------------ > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 02 October 2013 15:17 > *To:* DRAGE, Keith (Keith) > *Cc:* Paul Coverdale; CLUE > > *Subject:* Re: [clue] Its not "legacy", its ??? > **** > > ** ** > > "non-CLUE enabled" means the endpoint does not support the CLUE protocol > (at all) or the endpoint is not using the CLUE protocol for whatever reas= on > (e.g., fallback case)**** > > ** ** > > I think the "non-CLUE" is more in line with the original implication of > the term "legacy". **** > > ** ** > > Mary .**** > > ** ** > > On Wed, **Oct 2, 2013** at **9:12 AM**, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote:**** > > Just to add a pedantic point, I am not sure what a =93non-CLUE=94 is. Wha= t we > have is something where CLUE does not exist, not the creation of some oth= er > concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to apply= the > negation to the =93enabled=94 which is something like =93disabled=94, =93= unenabled=94 > or whatever.**** > > **** > > Keith**** > > **** > ------------------------------ > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 02 October 2013 14:57 > *To:* Paul Coverdale > *Cc:* CLUE**** > > > *Subject:* Re: [clue] Its not "legacy", its ???**** > > **** > > It is a fine line. I personally have a preference for "non-CLUE enabled"= . > I really don't think we'll be using that in too many places in the > documents that it's too much typing. If someone thinks that's the case, > perhaps we use "clueless" in the docs until we're ready to ship them out = of > the WG and then just do a global change. As I've said before for XCON, w= e > do use the term "non-XCON enabled" which I think has the right semantics > and really isn't too much of a mouthful to say either.**** > > **** > > Mary. **** > > **** > > On Wed, **Oct 2, 2013** at **8:35 AM**, Paul Coverdale < > coverdale@sympatico.ca> wrote:**** > > I thought the proposal of "clueless' was just a joke when I first saw it, > but apparently not. > > I think this term will just invite ridicule. It's a bit of a mouthful, bu= t > I > would suggest "non-CLUE" equipped". But if you insist on using "clueless"= , > at least hyphenate it (clue-less). > > ...Paul**** > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of*= * > ** > > >Paul Kyzivat > >Sent: Tuesday, **October 01, 2013** **5:40 PM** > >To: clue@ietf.org > >Subject: Re: [clue] Its not "legacy", its ??? > >**** > > >On 10/1/13 12:45 PM, Robert Hansen wrote: > >> I am personally very fond of 'CLUEless' :) > > > >One of the reasons I liked the name "clue" for the wg was because it > >gave us an excuse to use "clueless" and "clueful". However they do have > >the feel of "informal" usage - a bit odd for formal use. (But I can get > >over that.) > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 01/10/2013 17:22, Paul Kyzivat wrote: > >>> Mary, > >>> > >>> The minutes are now posted. We did talk about this, briefly. > >>> We decided we didn't want to use the meeting time to discuss what > >>> word to use - that we could do that on the list. > >>> > >>> I agree with you, I also think "legacy" has the wrong connotation for > >>> what we mean, so I would like to find a better term. I have no ideas > >>> that I love, but a couple that I could live with: "non-clue", > >"clueless". > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/1/13 10:26 AM, Mary Barnes wrote: > >>>> I'm in another meeting so unfortunately cannot attend today. But, I > >>>> would really, really like to get away from the term "legacy" - the > >>>> English language definition of "legacy" is not correct. CLUE isn't > >>>> superseding any functionality of current SIP endpoints. It's adding > >>>> additional functionality. I would much rather select something like > >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned > >>>> about the length of a more appropriate alternative term. > >>>> > >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is > >>>> slightly more appropriate since it's a different architecture and > >>>> entirely new application - i.e., it isn't based on RFC 3261, but > >>>> CLUE is, so any suggestion that it's replacing any current SIP > >>>> functionality isn't correct. > >>>> > >>>> Regards, > >>>> Mary. > >>>> > >>>> > >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> > wrote: > >>>> > >>>> You can find Christer's slides for today at: > >>>> > >>>>**** > > >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T > >>>> eam/CLUE_Legacy___1oct13.pptx > >>>> > >>>> > >>>> > >>>> *** > > >>>> /CLUE_Legacy_1oct13.pptx> > >>>> > >>>> > >>>> > >>>> See you shortly. > >>>> > >>>> Paul > >>>> _________________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > **** > > ** ** > --047d7bdc8e065647fa04e7c33654 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable --047d7bdc8e065647fa04e7c33654-- From mary.ietf.barnes@gmail.com Wed Oct 2 07:56:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604FD21F8412 for ; Wed, 2 Oct 2013 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbLHNQ860Q-N for ; Wed, 2 Oct 2013 07:55:59 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6F221F8467 for ; Wed, 2 Oct 2013 07:53:48 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id j7so4435065qaq.12 for ; Wed, 02 Oct 2013 07:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G4vm9s/cMMAKs26gavbRxHa4u23CkC9yKE+iHNkA9aA=; b=er+iTBPOG8aLI8wiroVxHfquWjEqUveCyhawwXM33pHZqS6pivB7yLoDfG5beHM3l7 aEDyPJmW5kDRSpz4MFwM1E0FfKnzIFD5CyAU8SsvA5IeHLc0pta0rNSIjilWBwoPXR6L TCBaCkffmxbd3kF9e7hXOAM2Jpcut2hXpJ+/idyfwWYenK4Jk0pw6eeJ7tZYoH1quN84 wnBmwRxrJlXxfmYNR08T3Fk10gPNgaloiuj27QgM4NJdmD/22eAVskwXCf71z4Lmx0Lf 7k2Dga2ijUhgUXi3HFKNzMq+wqJTNVaEc8B53uwnJqZzujCm6Cz3Ptk9rLDPkQYZrrBV LjMg== MIME-Version: 1.0 X-Received: by 10.224.171.133 with SMTP id h5mr2348488qaz.98.1380725627785; Wed, 02 Oct 2013 07:53:47 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 2 Oct 2013 07:53:47 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B244C@ESESSMB209.ericsson.se> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4B244C@ESESSMB209.ericsson.se> Date: Wed, 2 Oct 2013 09:53:47 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c2b78e939aea04e7c33c24 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 14:56:07 -0000 --001a11c2b78e939aea04e7c33c24 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 2, 2013 at 9:44 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I agree that "non-CLUE enabled" refers to an entity that doesn't support > CLUE, or for whatever reason does not want to use CLUE. > > > > But, still, even when a session is established between two CLUE enabled > clients, the initial Offer/Answer will be for a "non-CLUE session" - in > order to interwork with non-CLUE enabled devices. > [MB] Actually, you just don't know at that point. I don't think we even need to use the concept of "non-CLUE" at that point. I think we are (as usual) over-analyzing. [/MB] > Then, if both endpoints are CLUE enabled, the data channel will be > established, CLUE messages will be sent, and one or more CLUE specific > Offer/Answers will be sent. > > > > Regards, > > > > Christer > > > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul > Coverdale [coverdale@sympatico.ca] > *Sent:* Wednesday, 02 October 2013 5:21 PM > *To:* 'DRAGE, Keith (Keith)' > > *Cc:* 'CLUE' > *Subject:* Re: [clue] Its not "legacy", its ??? > > I=92m not sure I agree with your reasoning, Keith. It=92s the =93CLUE= =94 part > we want to negate, not whether it is enabled or not. If we negate > =93enabled=94, using =93disabled=92 or whatever, it would imply some othe= r type of > system which has CLUE capability, but for some reason doesn=92t want to u= se > it. > > > > > > ...Paul > > > > *From:* DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > *Sent:* Wednesday, October 02, 2013 10:13 AM > *To:* Mary Barnes; Paul Coverdale > *Cc:* CLUE > *Subject:* RE: [clue] Its not "legacy", its ??? > > > > Just to add a pedantic point, I am not sure what a =93non-CLUE=94 is. Wha= t we > have is something where CLUE does not exist, not the creation of some oth= er > concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to apply= the > negation to the =93enabled=94 which is something like =93disabled=94, =93= unenabled=94 > or whatever. > > > > Keith > > > ------------------------------ > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Mary Barnes > *Sent:* 02 October 2013 14:57 > *To:* Paul Coverdale > *Cc:* CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > > > It is a fine line. I personally have a preference for "non-CLUE enabled"= . > I really don't think we'll be using that in too many places in the > documents that it's too much typing. If someone thinks that's the case, > perhaps we use "clueless" in the docs until we're ready to ship them out = of > the WG and then just do a global change. As I've said before for XCON, w= e > do use the term "non-XCON enabled" which I think has the right semantics > and really isn't too much of a mouthful to say either. > > > > Mary. > > > > On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: > > I thought the proposal of "clueless' was just a joke when I first saw it, > but apparently not. > > I think this term will just invite ridicule. It's a bit of a mouthful, bu= t > I > would suggest "non-CLUE" equipped". But if you insist on using "clueless"= , > at least hyphenate it (clue-less). > > ...Paul > > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > >Paul Kyzivat > >Sent: Tuesday, October 01, 2013 5:40 PM > >To: clue@ietf.org > >Subject: Re: [clue] Its not "legacy", its ??? > > > > >On 10/1/13 12:45 PM, Robert Hansen wrote: > >> I am personally very fond of 'CLUEless' :) > > > >One of the reasons I liked the name "clue" for the wg was because it > >gave us an excuse to use "clueless" and "clueful". However they do have > >the feel of "informal" usage - a bit odd for formal use. (But I can get > >over that.) > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 01/10/2013 17:22, Paul Kyzivat wrote: > >>> Mary, > >>> > >>> The minutes are now posted. We did talk about this, briefly. > >>> We decided we didn't want to use the meeting time to discuss what > >>> word to use - that we could do that on the list. > >>> > >>> I agree with you, I also think "legacy" has the wrong connotation for > >>> what we mean, so I would like to find a better term. I have no ideas > >>> that I love, but a couple that I could live with: "non-clue", > >"clueless". > >>> > >>> Thanks, > >>> Paul > >>> > >>> On 10/1/13 10:26 AM, Mary Barnes wrote: > >>>> I'm in another meeting so unfortunately cannot attend today. But, I > >>>> would really, really like to get away from the term "legacy" - the > >>>> English language definition of "legacy" is not correct. CLUE isn't > >>>> superseding any functionality of current SIP endpoints. It's adding > >>>> additional functionality. I would much rather select something like > >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned > >>>> about the length of a more appropriate alternative term. > >>>> > >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is > >>>> slightly more appropriate since it's a different architecture and > >>>> entirely new application - i.e., it isn't based on RFC 3261, but > >>>> CLUE is, so any suggestion that it's replacing any current SIP > >>>> functionality isn't correct. > >>>> > >>>> Regards, > >>>> Mary. > >>>> > >>>> > >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> > wrote: > >>>> > >>>> You can find Christer's slides for today at: > >>>> > >>>> > > >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T > >>>> eam/CLUE_Legacy___1oct13.pptx > >>>> > >>>> > >>>> > >>>> > >>>> /CLUE_Legacy_1oct13.pptx> > >>>> > >>>> > >>>> > >>>> See you shortly. > >>>> > >>>> Paul > >>>> _________________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --001a11c2b78e939aea04e7c33c24 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 2, 2013 at 9:44 AM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

=A0

I agree that "non-CLUE enabled" refers to an entity that doesn= 't support CLUE, or for whatever reason does not want to use CLUE.

=A0

But, still, even when a session is established between two CLUE enabled = clients, the initial Offer/Answer will be for a "non-CLUE session"= ; - in order to interwork with non-CLUE enabled devices.

[MB] Actually, you just don't know at that point. =A0= I don't think we even need to use the concept of "non-CLUE" a= t that point. =A0 I think we are (as usual) over-analyzing. =A0[/MB]=A0

Then, if both endpoints are CLUE e= nabled, the data channel will be established, CLUE messages will be sent, and one or more CLUE specific = Offer/Answers will be sent.

=A0

Regards,

=A0

Christer

=A0

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Coverdale [coverdale@sympatico.ca]
Sent: Wednesday, 02 October 2013 5:21 PM
To: 'DRAGE, Keith (Keith)'

Cc: 'CLUE'
Subject: Re: [clue] Its not "legacy", its ???

I=92m not sure I agr= ee with your reasoning, Keith. It=92s the =93CLUE=94 part we want to negate= , not whether it is enabled or not. If we negate =93enabled=94, using =93disabled=92 or whatever, it would imply some other type of system= which has CLUE capability, but for some reason doesn=92t want to use it.

=A0

=A0

...Paul

=A0

From: DRAGE, Keith= (Keith) [mailto:keith.drage@alcatel-lucent.com]
Sent: Wednesday, October 02, 2013 10:13 AM
To: Mary Barnes; Paul Coverdale
Cc: CLUE
Subject: RE: [clue] Its not "legacy", its ???

=A0

Just to add a ped= antic point, I am not sure what a =93non-CLUE=94 is. What we have is someth= ing where CLUE does not exist, not the creation of some other concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to = apply the negation to the =93enabled=94 which is something like =93disabled= =94, =93unenabled=94 or whatever.

=A0

Keith

=A0

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57
To: Paul Coverdale
Cc: CLUE
Subject: Re: [clue] Its not "legacy", its ???

=A0

It is a fine line. =A0I persona= lly have a preference for "non-CLUE enabled". =A0 I really don= 9;t think we'll be using that in too many places in the documents that = it's too much typing. =A0If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to s= hip them out of the WG and then just do a global change. =A0As I've sai= d before for XCON, we do use the term "non-XCON enabled" which I = think has the right semantics and really isn't too much of a mouthful to say either.

=A0

Mary.=A0

= =A0

On Wed, Oct 2, 2013 at 8:35 AM,= Paul Coverdale <coverdale@sympatico.ca> wrote:

I thought the proposal of "= ;clueless' was just a joke when I first saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, = but I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original Message-----
>From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert= Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discu= ss what
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>> =A0 =A0 =A0Thanks,
>>> =A0 =A0 =A0Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend = today. =A0But, I
>>>> would really, really like to get away from the term "= legacy" - =A0the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. = =A0It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint". =A0 We can shorten = if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different archi= tecture and
>>>> entirely new application - i.e., it isn't based on RFC= 3261, but
>>>> CLUE is, so any suggestion that it's replacing any cur= rent SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>> =A0 =A0 You can find Christer's slides for today at: >>>>
>>>>

>>>> /CLUE_Legacy_1= oct13.pptx>
>>>>
>>>>
>>>>
>>>> =A0 =A0 See you shortly.
>>>>
>>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
>>>> =A0 =A0 _________________________________________________<= br> >>>> =A0 =A0 clue mailing list
>>>> =A0 =A0 clue@ietf.org <mailto:clue@ietf.org>
>>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue >>>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue&g= t;
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

=A0


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--001a11c2b78e939aea04e7c33c24-- From Mark.Duckworth@polycom.com Wed Oct 2 09:39:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F5021F9CAC for ; Wed, 2 Oct 2013 09:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAcsdy6pZkvc for ; Wed, 2 Oct 2013 09:39:25 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 805EE21F9A78 for ; Wed, 2 Oct 2013 09:38:15 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 2 Oct 2013 09:38:11 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 2 Oct 2013 09:38:10 -0700 Thread-Topic: [clue] Example of MCC Thread-Index: Ac6+SecojrBz/N5eTDO/8lkDz7GV3gBQHMvA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D603450392@CRPMBOXPRD07.polycom.com> References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> <5245FBA5.6060809@nteczone.com> <5249AA02.3020703@cisco.com> <524A2C70.6000106@nteczone.com> In-Reply-To: <524A2C70.6000106@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:39:36 -0000 Inline responses to Rob's and Christian's comments. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Monday, September 30, 2013 9:59 PM > To: clue@ietf.org > Subject: Re: [clue] Example of MCC > > Hello Rob, > > Please see my comments below. > > Regards, Christian > > On 1/10/2013 2:42 AM, Robert Hansen wrote: > > Hi Mark, Christian, > > > > See inline > > > > On 27/09/2013 22:41, Christian Groves wrote: > >> Hello Mark, > >> > >> Please see below. > >> > >> Regards, Christian > >> > >> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: > >>> Hi Christian, > >>> > >>> I agree the MCU provider can choose to provide as much or as little > >>> information as it wants. And I agree there could be optimizations > >>> to reduce CLUE message sizes. Given this, maybe it is enough to > >>> address the concerns about scaling to large conferences? What do > others think? > > > > [RH] I think so long as the provider isn't *required* to provide a > > capture corresponding to every participant in the conference then > > message sizing is much less of an issue, as it allows the MCU to make > > sensible choices about how much information to pass on. > [CNG] No intention to require the provider to provide a capture > corresponding to every participant. The intention is to have one mechanis= m > to allow both simple and complex scenarios. [Duckworth, Mark] Sounds good to me. > > [RH] I do think that if we adopt this approach it'll necessitate > > switching to a model where new advertisment messages are deltas of the > > previous, as opposed to complete refreshes (a la RFC 4575's > > partial/full update mechanism), so that if the MCU does want to send > > all participant capture information in a particularly large conference > > it has a mechanism for doing so without being required to send a vast > > XML document every time anyone leaves or joins. > [CNG] What do you see as the message size threshold to take us from a > complete refresh approach to a delta approach? Perhaps we should start > another thread on this topic? It was mentioned at the virtual interim tha= t > we'll go with the complete refresh approach but I think that was partiall= y due > to that it hasn't received any real discussion. [Duckworth, Mark] I agree this should be a separate discussion topic. > >>> About CapScene9, I have more questions. You suggested the MCU could > >>> do some image processing to ensure captures are the same size, and > >>> indicate this by using the same virtual area of capture for each of > >>> the MCCs. I agree, but I was not too concerned about the relative > >>> sizes of the captures from different endpoints. I am more concerned > >>> about the spatial relationship between captures from the same > >>> endpoint in terms of how to order them next to each other for proper > >>> rendering. The consumer should have enough information to do this > >>> if the MCU provides all the original spatial information from each > >>> endpoint in the advertisement, do you agree? > >> [CNG]Yes I agree. > >>> > >>> One downside to this approach is that every change the MCU makes in > >>> how it assigns contributing VCs to an MCC (e.g. make a switch based > >>> on current talker) could result in the consumer renderer needing to > >>> change how it maps decoder output to display locations. I need to > >>> think more about if this would really be a problem or not. > >> [CNG] For this switching case I would think that a consumer would use > >> the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would > >> always present the active speaker from the list of VC using the same > >> co-ordinates. Or are you talking about switching the positions in a > >> composed MCC? [Duckworth, Mark] I was not talking about a composed MCC. I think you are = saying in this example that MCC4 is the most active speaker, MCC5 is the ne= xt most active speaker, etc. and the MCU switches in the appropriate origin= al VC to make this policy happen, is that right? I'm thinking of the case = where the MCU is switching multiple VCs from the same originating endpoint = together, like the "site switch" policy we have talked about. So maybe MCC= 4, MCC5, and MCC6 contain the three VCs from the active speaker that is in = a three-camera room. Then MCC7 contains the next most active speaker from = another room, and MCC8-10 might be the third most active speaker from anoth= er three-camera room. And this mapping of which MCCs are showing portions = of the same room can change often. I thought using multiple scenes with sm= aller CSEs could help simplify this, which you agreed with below, so I gues= s we should focus on that rather than this CapScene9 example which has a la= rge CSE with 9 MCCs in it. But Rob might disagree, so more questions below= . > > [RH] My issue with using the spatial coordinates of the MCC is that it > > requires the MCU to anticipate the rendering desires of the endpoint, > > as the MCU will need to advertise MCCs with spatial coordinates that > > allow the endpoint to do what it wants to do. My concern has always > > been that this may lead to huge numbers of MCCs and capture scene > > entries if the MCU is trying to anticipate potential layouts by the > > endpoint. > [CNG] A consumer can choose to render how it sees fit. The spatial > information is a guide. If the MCU advertises a switched MCC showing the > most active speaker in the left position and a MCC showing the second mos= t > active speaker in the right position there's nothing stopping the consume= r > from swapping the positions when rendering. I don't think its up to an > Advertiser to provide every conceivable spatial layout. [Duckworth, Mark] With the multiple scenes approach, I see the MCU trying t= o anticipate the consumer's rendering desire only at a very high level. Th= at is the MCU can provide small sets of captures in a CSE advertised by the= MCU, while keeping VCs together in the same MCU CSE that originally come f= rom the same scene from the original endpoint provider. [Duckworth, Mark] Rob, are you suggesting a better approach is for the rend= erer to use just the spatial information of the original VCs, and not try t= o use MCU-generated spatial information about the MCCs? Basically followin= g the idea above - "The consumer should have enough information to do this = if the MCU provides all the original spatial information from each endpoint= in the advertisement" > >>> In my example (section 3.2 of my draft) I attempted to address this > >>> by using multiple scenes, where each scene had fewer VCs (these > >>> could become MCCs) in each CSE, with some spatial information the > >>> MCU would adhere to when switching. I'm still leaning toward this > >>> multiple scene idea. I think combining it with the MCC concept will > >>> be an improvement. > >> [CNG] I think the multiple scenes is the way to go. > > > > [RH] In terms of our definition of 'scene' it makes sense for the > > originating VCs to be seperate scenes (since in reality they are > > indeed seperate rooms), but as far as our current syntax goes then > > there is an issue with the fact that MCCs would want to reference VCs > > from different scenes. > [CNG] Yes I agree, this is detailed in my draft, sect 3.1.2 "/Note: > Section 6.1/[I-D.ietf-clue-framework] indicates that "A Media Capture is > associated with exactly one Capture Scene". For MCC this could be furthe= r > clarified to indicate that "A Media Capture is defined in a capture scene= and is > given an advertisement unique identity. The identity may be referenced > outside the Capture Scene// // that defines it through a multiple content > capture (MCC)./" > > > >>> > >>> Still about CapScene9, you wrote "the MCC could change the location o= f > >>> the capture areas in virtual space to suggest some sort of layout to = a > >>> consumer. The 3rd option is not to send spatial information." I don't > >>> understand what you mean, could you expand on this please? > >> [CNG] The first part of the sentence refers to be capability to order > >> them next to each other as you mention above. The 3rd option is to onl= y > >> send spatial information related to the MCC and not the VCs. In that > >> case the consumer only knows the overall capture area of the MCC not > the > >> spatial area of the components. > >>> > >>> Regards, > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] > >>>> Sent: Thursday, September 26, 2013 9:43 PM > >>>> To: Duckworth, Mark > >>>> Cc: clue@ietf.org > >>>> Subject: Re: Example of MCC > >>>> > >>>> Hello Mark, > >>>> > >>>> Please see my responses below. > >>>> > >>>> Regards, Christian > >>>> > >>>> On 27/09/2013 3:29 AM, Duckworth, Mark wrote: > >>>>> Hello Christian, > >>>>> > >>>>> Thanks for the example, this is a good basis for discussion. > >>>>> > >>>>> One new key concept here is that CapScene2 through CapScene7 > include > >>>> media captures that are not associated with any encoding group. Thi= s > >>>> indicates the consumer cannot ask for these captures directly in a > >>>> configure > >>>> message, because there is no way for the consumer to ask for a > capture > >>>> encoding of any of these captures directly. I have considered this > >>>> idea > >>>> before, and it does seem useful. This MCC example is taking this > >>>> approach > >>>> with the MCU advertising all the other endpoints' captures, to give > >>>> information about them, but not for directly putting into capture > >>>> encodings > >>>> sent from the MCU. > >>>> [CNG] Yes that's correct. > >>>>> However, there could be issues in scaling to large conferences. > >>>>> Here are > >>>> two points from draft-duckworth-clue-switching-example-01 (originall= y > >>>> from > >>>> draft-hansen-clue-consumer-layout): > >>>>> 1. The mixer could advertise all the other endpoint's captures, but > >>>>> as the > >>>> size of the conference increases the number of captures that must be > >>>> advertised will quickly become impractical. > >>>>> 2. If the renderer had all the spatial information about all > >>>>> possible original > >>>> source captures it might receive, it would enable correct spatial > >>>> rendering. > >>>> But as the number of captures per endpoint and the number of > >>>> endpoints in > >>>> a conference rise caching all the data becomes impractical. > >>>> [CNG] I think the above are just a natural consequence that as the > >>>> number of > >>>> endpoints increase so will the amount of information that needs to b= e > >>>> signalled. I think the key point is that with the MCC concept the MC= U > >>>> has to > >>>> choice to provide as much or as little information as it wants. It > >>>> doesn't have > >>>> to pass on all the information that it receives in the source > >>>> captures, it can > >>>> filter or manipulate the information as it sees fit. > >>>> > >>>> With regards to the 2nd point the MCC concept allows the MCU to > >>>> provide > >>>> "harmonised" spatial information regarding the MCC which means the > a > >>>> Consumer could use this information rather than source spatial > >>>> information if > >>>> conference size becomes a problem. > >>>>> I'm not sure what the practical limit on conference size would be. > >>>>> Maybe > >>>> there are reasonable ways to do this in large conferences. This > >>>> needs further > >>>> thought. > >>>> [CNG] I don't see that CLUE needs to place any limits on the > >>>> conference size. > >>>> I think its largely an endpoint decision on the amount of informatio= n > >>>> it wants > >>>> to provide. I think there are potential optimisation we can do in th= e > >>>> coding of > >>>> CLUE that will minimise the size of messages. For example > >>>> introducing a > >>>> "range" concept to CSEs/MCCs/STSs that could allow to specify a > >>>> group of > >>>> captures without specifying every one. > >>>> > >>>> > MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > >>>> Captures:1}{Policy1}{Encodinggroup1} > >>>> could be signalled as: > >>>> MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} > >>>> > >>>> Likewise a CSE for CaptureScene9 > >>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) > >>>> could be signalled as: > >>>> CSE(MCC4-MCC12) > >>>> > >>>> > >>>>> CapScene8 below is essentially the same idea as the "advertising > >>>>> multiple > >>>> scenes" example in draft-duckworth-clue-switching-example-01, > section > >>>> 3.2. > >>>> CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. = I > >>>> assume > >>>> CapScene8 would include spatial information for MCC1, MCC2, and > MCC3. > >>>> And also I suggest CapScene8 could include other CSEs with fewer > >>>> captures, > >>>> such as: > >>>> > MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > >>>> Captures:1}{Policy1}{Encodinggroup1} > >>>> > MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > >>>> Captures:1}{Policy1}{Encodinggroup2} > >>>> > MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > >>>> Captures:1}{Policy1}{Encodinggroup1} > >>>>> CSE9(MCC100,MCC101) > >>>>> CSE10(MCC102) > >>>>> These CSEs would be useful for one or two screen consumers. > >>>> [CNG] Yes multiple Capture Scenes are used so this aspect parallels > >>>> section > >>>> 3.2 in your draft. Yes I agree that Capture8 could include CSEs with > >>>> fewer > >>>> captures as you suggest. > >>>> > >>>>> I have questions about how to use CapScene9 in the example below. > >>>> Would MCC4 through MCC12 have any spatial information? If so, what > >>>> would > >>>> it be? Or does the consumer rely solely on the spatial information > >>>> of VC4 > >>>> through VC15, along with some way of knowing which specific VC it is > >>>> receiving (within an MCC encoding) at any given time? > >>>> [CNG] Potentially MCC4 through MCC12 could have spatial > >>>> information. An > >>>> advertiser could supply the same "virtual" capture area on each MCC > >>>> (i.e. a MCU may do some image processing to ensure they captures > >>>> are the > >>>> same size) that way the consumer knows the MCCs are the same size. > >>>> Alternatively the MCC could change the location of the capture > >>>> areas in > >>>> virtual space to suggest some sort of layout to a consumer. The 3rd > >>>> option is not to send spatial information. The above would be the > >>>> switching case. > >>>> > >>>> In a composition case the Advertiser could provide a "harmonised" > >>>> virtual capture area on the MCC and it could provide capture area > >>>> information on the individual VCs to give their layout in the > >>>> "harmonised" capture area. > >>>> > >>>> > >>>>> Would CapScene9 also include other CSEs with fewer media captures > in > >>>> them, indicating a consumer could choose fewer media captures and > >>>> still get > >>>> a "representation of the whole scene" without receiving all 9 MCCs? > >>>> [CNG] CapScene9 could include CSEs with fewer captures. It would > come > >>>> down to whether the Advertiser considers MCC4-MCC12 (or a subset > >>>> of) as > >>>> representations of the overall scene or just as individual > >>>> supplementary > >>>> streams. > >>>>> Regards, > >>>>> Mark > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] > >>>>>> Sent: Tuesday, September 17, 2013 11:16 PM > >>>>>> To: Duckworth, Mark; clue@ietf.org > >>>>>> Subject: Example of MCC > >>>>>> > >>>>>> Hello Mark, > >>>>>> > >>>>>> At yesterday's interim you asked if I could use the MCC concept > >>>>>> (draft-groves-clue-multi-content-00) to support the example in you= r > >>>>>> draft > >>>> ( > >>>>>> draft-duckworth-clue-switching-example-01). I assume that you > were > >>>> talking > >>>>>> about the scenario in section 2. > >>>>>> > >>>>>> I think it is worthwhile to consider the "Endpoint" advertisements > >>>>>> also. > >>>>>> From a CLUE perspective how an endpoint chooses to render the > >>>> received > >>>>>> encodings is largely irrelevant as it is up to the local policy. > >>>>>> > >>>>>> I would assume the source Advertisements would be something > like: > >>>>>> > >>>>>> Endpoint A - 4 screens, 3 cameras > >>>>>> Endpoint B - 3 screens, 3 cameras > >>>>>> Endpoint C - 3 screens, 3 cameras > >>>>>> Endpoint D - 3 screens, 3 cameras > >>>>>> > >>>>>> Endpoints A-D: > >>>>>> CaptureScene1[Description=3DEndpoint > x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] > >>>>>> > >>>>>> Endpoints E-G: > >>>>>> CaptureScene1[Description=3DEndpoint y,VC1,CSE(VC1)] > >>>>>> > >>>>>> Note: The endpoints would be likely to use the same IDs in their > >>>> respective > >>>>>> Advertisements. > >>>>>> > >>>>>> Rather than considering what is displayed the MCC concepts > >>>>>> concentrates > >>>>>> more on what the MCU/Mixer sends. The mixer doesn't know > anything > >>>>>> about the number of screens an endpoint has. > >>>>>> > >>>>>> My assumption from the figures is that if the 3 main screens are > >>>>>> "site" > >>>>>> switching that there is one capture encoding/media stream for each= . > >>>>>> The > >>>>>> MCU switches in the applicable media into the stream based on > voice > >>>> activity > >>>>>> [policy1]. I assume endpoint A will not see a capture from > >>>>>> itself. The > >>>>>> descriptions are just for information. > >>>>>> > >>>>>> Using the MCC concept the MCU would Advertise to endpoint A: > >>>>>> ----------------------------------------------------------- > >>>>>> > >>>>>> CapScene2[Description=3DEndpoint > B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] > >>>>>> > >>>>>> CapScene3[Description=3DEndpoint > C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] > >>>>>> > >>>>>> CapScene4[Description=3DEndpoint > >>>>>> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] > >>>>>> > >>>>>> CapScene5[Description=3DEndpoint E,VC13,(CSE5(VC13)] > >>>>>> > >>>>>> CapScene6[Description=3DEndpoint F,VC14,(CSE6(VC13)] > >>>>>> > >>>>>> CapScene7[Description=3DEndpoint G,VC15,(CSE7(VC13)] > >>>>>> > >>>>>> // The above part effectively is the same as the input > >>>>>> advertisements. > >>>>>> There are no capture encodings associated with them. > >>>>>> > >>>>>> CapScene8[Description=3DOutput3streammix, > >>>>>> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} > >>>>>> {Encodinggroup1} > >>>>>> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) > >>>>>> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} > >>>>>> {Encodinggroup2} > >>>>>> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} > >>>>>> {Encodinggroup3} > >>>>>> CSE8(MCC1,MCC2,MCC3) > >>>>>> > >>>>>> // The above part describes the switched 3 main streams that > >>>>>> relate to > >>>> site > >>>>>> switching. MaxCaptures:1 indicates that only one capture from the > >>>>>> MCC is > >>>>>> sent at a particular time. The default if it wasn't included is 1 > >>>>>> so it doesn't > >>>>>> need to be sent but included for clarity. Sync-id:1 indicates that > >>>>>> the source > >>>>>> sending is synchronised. Therefore when MCC2 contains > VC13,VC14,VC15 > >>>>>> nothing will be sent in the other MCCs. > >>>>>> > >>>>>> CapScene9[Description=3DOutput9streams, > >>>>>> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} > >>>>>> > >>>>>> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} > >>>>>> > >>>>>> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} > >>>>>> > >>>>>> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} > >>>>>> > >>>>>> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} > >>>>>> > >>>>>> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} > >>>>>> > >>>>>> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} > >>>>>> > >>>>>> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} > >>>>>> > >>>>>> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} > >>>>>> > >>>>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] > >>>>>> > >>>>>> // The above part indicates that there are 9 capture encodings. > >>>>>> Each of > >>>> the > >>>>>> capture encodings may contain any captures from any source site > >>>>>> with a > >>>>>> maximum of one capture at a time. Which capture is present is > >>>> determined > >>>>>> by Policy2. > >>>>>> > >>>>>> If the MCU wanted to provide a composed capture encoding of the 9 > >>>>>> captures it could Advertise in addition: > >>>>>> CapScene10[Description=3DNineTiles, > >>>>>> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >>>>>> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} > >>>>>> CSE(MCC13) > >>>>>> // As maxcaptures is 9 it indicates that the capture encoding > >>>>>> contains > >>>>>> information from up to 9 sources at a time. > >>>>>> > >>>>>> [CNG] The above arrangement allows a Consumer to understand > how the > >>>>>> captures relate to the source sites. It means a Consumer can choos= e > >>>>>> not > >>>> to > >>>>>> receive information from a particular source. This is not possible > >>>>>> according > >>>> to > >>>>>> the "one big scene" approach below. > >>>>>> > >>>>>> The Advertisement for Endpoint B in your draft would be identical > >>>>>> to the > >>>>>> above other than the captures from Endpoint A would be added and > the > >>>>>> captures from Endpoint B would be removed. > >>>>>> > >>>>>> I hope this provides some clarification. > >>>>>> > >>>>>> Regards, Christian > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From coverdale@sympatico.ca Wed Oct 2 10:20:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D51521F9DA0 for ; Wed, 2 Oct 2013 10:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZA-WDtpypk9q for ; Wed, 2 Oct 2013 10:20:20 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by ietfa.amsl.com (Postfix) with ESMTP id 972C321F9BD0 for ; Wed, 2 Oct 2013 10:17:00 -0700 (PDT) Received: from BLU0-SMTP40 ([65.55.111.73]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 10:17:00 -0700 X-TMN: [QxbVt2yBUMwycLoZaHfcSkkqnnF4F4J1] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([184.147.39.162]) by BLU0-SMTP40.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 10:16:50 -0700 From: Paul Coverdale To: "'DRAGE, Keith \(Keith\)'" References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE963@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AE963@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Wed, 2 Oct 2013 13:16:46 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01CEBF71.A6A98420" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unAAhI+uA///l8wD//9rPkP//tAiA//9isYD//prbEA== Content-Language: en-us X-OriginalArrivalTime: 02 Oct 2013 17:16:51.0296 (UTC) FILETIME=[2F2DEE00:01CEBF93] Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:20:32 -0000 ------=_NextPart_000_0081_01CEBF71.A6A98420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well, we can add a few more: "CLUE agnostic" "CLUE couldn't care less" "CLUE what's all this fuss about anyway" ...... But if you want to get away from "non" in front of CLUE, your proposal of "CLUE unsupported" seems reasonable to cover what we are looking for. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:45 AM To: Paul Coverdale Cc: 'CLUE' Subject: RE: [clue] Its not "legacy", its ??? That is just saying the negative chosen is the wrong one. "CLUE unsupported" "CLUE inhibited" "CLUE disallowed" "CLUE frustrated" Keith _____ From: Paul Coverdale [mailto:coverdale@sympatico.ca] Sent: 02 October 2013 15:22 To: DRAGE, Keith (Keith) Cc: 'CLUE' Subject: RE: [clue] Its not "legacy", its ??? I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we want to negate, not whether it is enabled or not. If we negate "enabled", using "disabled' or whatever, it would imply some other type of system which has CLUE capability, but for some reason doesn't want to use it. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:13 AM To: Mary Barnes; Paul Coverdale Cc: CLUE Subject: RE: [clue] Its not "legacy", its ??? Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we have is something where CLUE does not exist, not the creation of some other concept of a "non-CLUE" to complement a "CLUE". You want to apply the negation to the "enabled" which is something like "disabled", "unenabled" or whatever. Keith _____ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". I really don't think we'll be using that in too many places in the documents that it's too much typing. If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship them out of the WG and then just do a global change. As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>> > wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0081_01CEBF71.A6A98420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, we can add a few more:

 

“CLUE agnostic”

“CLUE couldn’t care less”

“CLUE what’s all this fuss about = anyway”

......

 

But if you want to get away from “non” in front of CLUE, = your proposal of “CLUE unsupported” seems reasonable to = cover what we are looking for.

 

...Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] =
Sent: Wednesday, October 02, 2013 10:45 AM
To: Paul = Coverdale
Cc: 'CLUE'
Subject: RE: [clue] Its not = "legacy", its ???

 

Th= at is just saying the negative chosen is the wrong = one.

 

&#= 8220;CLUE unsupported”

 

&#= 8220;CLUE inhibited”

 

&#= 8220;CLUE disallowed”

 

&#= 8220;CLUE frustrated”

 

Ke= ith

 

From:= = Paul Coverdale [mailto:coverdale@sympatico.ca]=
Sent: 02 October 2013 15:22
To: DRAGE, Keith = (Keith)
Cc: 'CLUE'
Subject: RE: [clue] Its not = "legacy", its ???

 

I’m not sure I agree with your reasoning, Keith. It’s the = “CLUE” part we want to negate, not whether it is enabled or = not. If we negate “enabled”, using “disabled’ or = whatever, it would imply some other type of system which has CLUE = capability, but for some reason doesn’t want to use = it.

 

 

...Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel= -lucent.com]
Sent: Wednesday, October 02, 2013 10:13 = AM
To: Mary Barnes; Paul Coverdale
Cc: = CLUE
Subject: RE: [clue] Its not "legacy", its = ???

 

Ju= st to add a pedantic point, I am not sure what a “non-CLUE” = is. What we have is something where CLUE does not exist, not the = creation of some other concept of a “non-CLUE” to complement = a “CLUE”. You want to apply the negation to the = “enabled” which is something like “disabled”, = “unenabled” or whatever.

 

Ke= ith

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Mary Barnes
Sent: 02 October 2013 = 14:57
To: Paul Coverdale
Cc: CLUE
Subject: = Re: [clue] Its not "legacy", its = ???

 

It is a fine line.  I personally have a preference for = "non-CLUE enabled".   I really don't think we'll be using = that in too many places in the documents that it's too much typing. =  If someone thinks that's the case, perhaps we use = "clueless" in the docs until we're ready to ship them out of = the WG and then just do a global change.  As I've said before for = XCON, we do use the term "non-XCON enabled" which I think has = the right semantics and really isn't too much of a mouthful to say = either.

 

Mary. 

 

On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> = wrote:

I = thought the proposal of "clueless' was just a joke when I first saw = it,
but apparently not.

I think this term will just invite = ridicule. It's a bit of a mouthful, but I
would suggest = "non-CLUE" equipped". But if you insist on using = "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original = Message-----
>From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 = 5:40 PM
>To: clue@ietf.org
>Subject: Re: = [clue] Its not "legacy", its = ???
>

>On 10/1/13 12:45 PM, Robert = Hansen wrote:
>> I am personally very fond of 'CLUEless' = :)
>
>One of the reasons I liked the name "clue" = for the wg was because it
>gave us an excuse to use = "clueless" and "clueful". However they do = have
>the feel of "informal" usage - a bit odd for = formal use. (But I can get
>over that.)
>
>   =     Thanks,
>       = Paul
>
>> Rob
>>
>> On 01/10/2013 = 17:22, Paul Kyzivat wrote:
>>> = Mary,
>>>
>>> The minutes are now posted. We did = talk about this, briefly.
>>> We decided we didn't want to = use the meeting time to discuss what
>>> word to use - that = we could do that on the list.
>>>
>>> I agree = with you, I also think "legacy" has the wrong connotation = for
>>> what we mean, so I would like to find a better term. = I have no ideas
>>> that I love, but a couple that I could = live with: = "non-clue",
>"clueless".
>>>
>= ;>>      Thanks,
>>>     =  Paul
>>>
>>> On 10/1/13 10:26 AM, Mary = Barnes wrote:
>>>> I'm in another meeting so = unfortunately cannot attend today.  But, I
>>>> = would really, really like to get away from the term "legacy" - =  the
>>>> English language definition of = "legacy" is not correct. CLUE isn't
>>>> = superseding any functionality of current SIP endpoints.  It's = adding
>>>> additional functionality. I would much rather = select something like
>>>> "non-Clue enabled = endpoint".   We can shorten if folks are = concerned
>>>> about the length of a more appropriate = alternative term.
>>>>
>>>> As an aside, = IMHO, the RTCWEB folks using the term "legacy" = is
>>>> slightly more appropriate since it's a different = architecture and
>>>> entirely new application - i.e., it = isn't based on RFC 3261, but
>>>> CLUE is, so any = suggestion that it's replacing any current SIP
>>>> = functionality isn't correct.
>>>>
>>>> = Regards,
>>>> = Mary.
>>>>
>>>>
>>>> On = Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>&g= t;>> <mailto:pkyzivat@alum.mit.edu>> = wrote:
>>>>
>>>>     You can = find Christer's slides for today = at:
>>>>
>>>>

>>>> = /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
&= gt;>>>
>>>>     See you = shortly.
>>>>
>>>>       =        Paul
>>>>     = _________________________________________________
>>>> =     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>> =     https://www.ietf.org/mailman/__listinfo/clue
>= ;>>>     <https://www.ietf.org/mailman/listinfo/clue>
&= gt;>>>
>>>>
>>>
>>> = _______________________________________________
>>> clue = mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>> = _______________________________________________
>> clue mailing = list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>
>_______________________________________________
>= ;clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_= ______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------=_NextPart_000_0081_01CEBF71.A6A98420-- From michael.hammer@yaanatech.com Wed Oct 2 10:46:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4421F9E1D for ; Wed, 2 Oct 2013 10:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z569QcFOtsrp for ; Wed, 2 Oct 2013 10:46:10 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id BCDF721F86B2 for ; Wed, 2 Oct 2013 10:43:43 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 2 Oct 2013 10:43:43 -0700 From: Michael Hammer To: "coverdale@sympatico.ca" , "keith.drage@alcatel-lucent.com" Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOvsKXtGOlmXKQAEalJwppz8lBEJnggw+AgABSdQCAAQqxAIAABh8AgAAEYACAAAKPgIAABo0AgAAqWwD//5IUQA== Date: Wed, 2 Oct 2013 17:43:42 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEE0881@sc9-ex2k10mb1.corp.yaanatech.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE963@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.216] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CE_01CEBF75.67E2F8D0" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 17:46:20 -0000 ------=_NextPart_000_00CE_01CEBF75.67E2F8D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01CEBF75.67E2F8D0" ------=_NextPart_001_00CF_01CEBF75.67E2F8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Or just call it pre-CLUE. Mike From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Coverdale Sent: Wednesday, October 02, 2013 1:17 PM To: 'DRAGE, Keith (Keith)' Cc: 'CLUE' Subject: Re: [clue] Its not "legacy", its ??? Well, we can add a few more: "CLUE agnostic" "CLUE couldn't care less" "CLUE what's all this fuss about anyway" ...... But if you want to get away from "non" in front of CLUE, your proposal of "CLUE unsupported" seems reasonable to cover what we are looking for. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:45 AM To: Paul Coverdale Cc: 'CLUE' Subject: RE: [clue] Its not "legacy", its ??? That is just saying the negative chosen is the wrong one. "CLUE unsupported" "CLUE inhibited" "CLUE disallowed" "CLUE frustrated" Keith _____ From: Paul Coverdale [mailto:coverdale@sympatico.ca] Sent: 02 October 2013 15:22 To: DRAGE, Keith (Keith) Cc: 'CLUE' Subject: RE: [clue] Its not "legacy", its ??? I'm not sure I agree with your reasoning, Keith. It's the "CLUE" part we want to negate, not whether it is enabled or not. If we negate "enabled", using "disabled' or whatever, it would imply some other type of system which has CLUE capability, but for some reason doesn't want to use it. ...Paul From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Wednesday, October 02, 2013 10:13 AM To: Mary Barnes; Paul Coverdale Cc: CLUE Subject: RE: [clue] Its not "legacy", its ??? Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we have is something where CLUE does not exist, not the creation of some other concept of a "non-CLUE" to complement a "CLUE". You want to apply the negation to the "enabled" which is something like "disabled", "unenabled" or whatever. Keith _____ From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". I really don't think we'll be using that in too many places in the documents that it's too much typing. If someone thinks that's the case, perhaps we use "clueless" in the docs until we're ready to ship them out of the WG and then just do a global change. As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>> > wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_001_00CF_01CEBF75.67E2F8D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Or just call it pre-CLUE.

 

Mike

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Paul Coverdale
Sent: Wednesday, October 02, 2013 1:17 = PM
To: 'DRAGE, Keith (Keith)'
Cc: = 'CLUE'
Subject: Re: [clue] Its not "legacy", its = ???

 

Well, we can add a few more:

 

“CLUE agnostic”

“CLUE couldn’t care less”

“CLUE what’s all this fuss about = anyway”

......

 

But if you want to get away from “non” in front of CLUE, = your proposal of “CLUE unsupported” seems reasonable to = cover what we are looking for.

 

...Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.dra= ge@alcatel-lucent.com]
Sent: Wednesday, October 02, 2013 = 10:45 AM
To: Paul Coverdale
Cc: = 'CLUE'
Subject: RE: [clue] Its not "legacy", its = ???

 

Th= at is just saying the negative chosen is the wrong = one.

 

&#= 8220;CLUE unsupported”

 

&#= 8220;CLUE inhibited”

 

&#= 8220;CLUE disallowed”

 

&#= 8220;CLUE frustrated”

 

Ke= ith

 

From:= = Paul Coverdale [mailto:coverdale@sympatico.ca]=
Sent: 02 October 2013 15:22
To: DRAGE, Keith = (Keith)
Cc: 'CLUE'
Subject: RE: [clue] Its not = "legacy", its ???

 

I’m not sure I agree with your reasoning, Keith. It’s the = “CLUE” part we want to negate, not whether it is enabled or = not. If we negate “enabled”, using “disabled’ or = whatever, it would imply some other type of system which has CLUE = capability, but for some reason doesn’t want to use = it.

 

 

...Paul

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel= -lucent.com]
Sent: Wednesday, October 02, 2013 10:13 = AM
To: Mary Barnes; Paul Coverdale
Cc: = CLUE
Subject: RE: [clue] Its not "legacy", its = ???

 

Ju= st to add a pedantic point, I am not sure what a “non-CLUE” = is. What we have is something where CLUE does not exist, not the = creation of some other concept of a “non-CLUE” to complement = a “CLUE”. You want to apply the negation to the = “enabled” which is something like “disabled”, = “unenabled” or whatever.

 

Ke= ith

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Mary Barnes
Sent: 02 October 2013 = 14:57
To: Paul Coverdale
Cc: CLUE
Subject: = Re: [clue] Its not "legacy", its = ???

 

It is a fine line.  I personally have a preference for = "non-CLUE enabled".   I really don't think we'll be using = that in too many places in the documents that it's too much typing. =  If someone thinks that's the case, perhaps we use = "clueless" in the docs until we're ready to ship them out of = the WG and then just do a global change.  As I've said before for = XCON, we do use the term "non-XCON enabled" which I think has = the right semantics and really isn't too much of a mouthful to say = either.

 

Mary. 

 

On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> = wrote:

I = thought the proposal of "clueless' was just a joke when I first saw = it,
but apparently not.

I think this term will just invite = ridicule. It's a bit of a mouthful, but I
would suggest = "non-CLUE" equipped". But if you insist on using = "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original = Message-----
>From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On = Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 = 5:40 PM
>To: clue@ietf.org
>Subject: Re: = [clue] Its not "legacy", its = ???
>

>On 10/1/13 12:45 PM, Robert = Hansen wrote:
>> I am personally very fond of 'CLUEless' = :)
>
>One of the reasons I liked the name "clue" = for the wg was because it
>gave us an excuse to use = "clueless" and "clueful". However they do = have
>the feel of "informal" usage - a bit odd for = formal use. (But I can get
>over that.)
>
>   =     Thanks,
>       = Paul
>
>> Rob
>>
>> On 01/10/2013 = 17:22, Paul Kyzivat wrote:
>>> = Mary,
>>>
>>> The minutes are now posted. We did = talk about this, briefly.
>>> We decided we didn't want to = use the meeting time to discuss what
>>> word to use - that = we could do that on the list.
>>>
>>> I agree = with you, I also think "legacy" has the wrong connotation = for
>>> what we mean, so I would like to find a better term. = I have no ideas
>>> that I love, but a couple that I could = live with: = "non-clue",
>"clueless".
>>>
>= ;>>      Thanks,
>>>     =  Paul
>>>
>>> On 10/1/13 10:26 AM, Mary = Barnes wrote:
>>>> I'm in another meeting so = unfortunately cannot attend today.  But, I
>>>> = would really, really like to get away from the term "legacy" - =  the
>>>> English language definition of = "legacy" is not correct. CLUE isn't
>>>> = superseding any functionality of current SIP endpoints.  It's = adding
>>>> additional functionality. I would much rather = select something like
>>>> "non-Clue enabled = endpoint".   We can shorten if folks are = concerned
>>>> about the length of a more appropriate = alternative term.
>>>>
>>>> As an aside, = IMHO, the RTCWEB folks using the term "legacy" = is
>>>> slightly more appropriate since it's a different = architecture and
>>>> entirely new application - i.e., it = isn't based on RFC 3261, but
>>>> CLUE is, so any = suggestion that it's replacing any current SIP
>>>> = functionality isn't correct.
>>>>
>>>> = Regards,
>>>> = Mary.
>>>>
>>>>
>>>> On = Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>&g= t;>> <mailto:pkyzivat@alum.mit.edu>> = wrote:
>>>>
>>>>     You can = find Christer's slides for today = at:
>>>>
>>>>

>>>> = /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
&= gt;>>>
>>>>     See you = shortly.
>>>>
>>>>       =        Paul
>>>>     = _________________________________________________
>>>> =     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>> =     https://www.ietf.org/mailman/__listinfo/clue
>= ;>>>     <https://www.ietf.org/mailman/listinfo/clue>
&= gt;>>>
>>>>
>>>
>>> = _______________________________________________
>>> clue = mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>> = _______________________________________________
>> clue mailing = list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>&= gt;
>
>_______________________________________________
>= ;clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

_= ______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

 

------=_NextPart_001_00CF_01CEBF75.67E2F8D0-- ------=_NextPart_000_00CE_01CEBF75.67E2F8D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTAw MjE3NDM0MVowIwYJKoZIhvcNAQkEMRYEFJpHO2sKOjhyO0bETdaICHuJ4K5KMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEACPRVU16hsA6Ajv9GL4gK6FEyamPOm4WosMviE54T NDj0yxX2RR4jxS7A2+Itc+0dtOVAOIek+I10kIBHzBETa0HeFxy6UiUkJg0VwROxNrYd/qQTUj9H 0m/ecqQK25YA6Xw94F6lC9YA70adPAFkgzcg9DwezGNR0CavkDtrsKqN9naM/EX+A7GKlaWdBpNt qWoa3KaLHeqq1BMoQlaWBPE/8nd8bY+z5OtaSJbI7Uzl4wU4SGyFy+SEMpWJtdKhseRef3NeBzVr +6+M05VDAOTRnAdOhwLcJAESYVToqFotYk7OA/IoGWW3oqn9NNcBGZvk1iavjBTjwo0qW+02HgAA AAAAAA== ------=_NextPart_000_00CE_01CEBF75.67E2F8D0-- From pkyzivat@alum.mit.edu Wed Oct 2 13:37:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1134C21F9D8B for ; Wed, 2 Oct 2013 13:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNeL2Sfg-nXv for ; Wed, 2 Oct 2013 13:36:46 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id F126F21F9D89 for ; Wed, 2 Oct 2013 13:36:38 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id YDnj1m0051vXlb85ALcWiX; Wed, 02 Oct 2013 20:36:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id YLcW1m0073ZTu2S3dLcWV3; Wed, 02 Oct 2013 20:36:30 +0000 Message-ID: <524C83CC.5050309@alum.mit.edu> Date: Wed, 02 Oct 2013 16:36:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1C4B244C@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380746190; bh=R4gzshK7OiZLIghi92HB9kykGHQMK4mOTcXf/rQ3cnI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TibAf0/YKNFJq7UjFvjJMQLR8e7uSymOBtCPEIy3gcLriGZFv1yx9So4YT8I/klAn gLOMIsieRDiD4z6yWxB8aj29Xjt3RfUuRgMIwgoHx/sOgv3G5Y/VtIoxMCZFsf56wC xav9PBWfR2Fq36rpdLahjNdfFoRlzAmiiu7qANR2uNWAH/TslRxJzElbYct437bB6E ajYmQhDnHhSm2cQFtgzTLdki4PHIFb14y3IB/+pP/FHGQSj16mWyU2PdbhRmvfEwzA gjMjhAMAi2zWAsyywYFC9KS2b8TM604KSGzdymWqfFim03lPuYRy/o8Ttu/rxsetiS OLKYrtPNY6N+A== Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 20:37:00 -0000 I think I am in agreement with Mary!!! In practice we can't distinguish between an endpoint that is incapable of supporting clue and one that chooses not to support clue. And that is true even if it was previously supporting clue in the session. (Perhaps it is mobile, and can change from a state where it supports clue to one where it does not.) We do have endpoints that claim conformance to CLUE, and others that don't. A given session can be using CLUE, or not. If the session is using CLUE, then both endpoints support CLUE. We can write specifications for how both ends are to behave in that case. We can also write specifications for how an endpoint supporting CLUE is to behave in a session where SIP without CLUE is in use. But in that case we can't specify any behavior for the other end other that referencing other specs that it might be supporting. We are using the "CLUE channel" in two ways: to indicate support for CLUE, and to do CLUE specific signaling. But it need not be the case that the absence of a CLUE channel means that we are not using CLUE in the session. If we got a CLUE channel up and were using CLUE on a session, and then the channel breaks for some reason, then we don't have a clue channel, but I think we are still using clue on the session. Then our specification can contain rules for what to do to either reestablish the channel, or continue using clue in a degraded mode without it, or stop using CLUE on the session. We could (if we wanted) define a way to explicitly drop the clue channel and continue in degraded mode without it. I think the following state machine describes the state of a *session*: (This *should* display in fixed width.) +----------+ +----------+ | STARTING |---->| CLUELESS | +----------+ +----------+ | ^ v | +-----------------------+-------+ | CLUEFUL | | +---------+ | | | Channel |<----------+ | | | Open | | | | +---------+ | | | ^ | | | | | | | v v | | +---------+ +---------+ | | | Channel |----->| Channel | | | | Broken | | Closed | | | +---------+ +---------+ | +-------------------------------+ I've used CLUEFUL and CLUELESS above for convenience, but CLUE-mode and non-CLUE-mode would probably be more suitable formal terms. If we were to follow the above, then we would need to specify the exact conditions that cause state transitions. In particular, how to distinguish between CLUELESS and CLUEFUL with channel broken or closed. Thanks, Paul From Christian.Groves@nteczone.com Wed Oct 2 21:04:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FA221F8467 for ; Wed, 2 Oct 2013 21:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9wbPBrrV9Jw for ; Wed, 2 Oct 2013 21:04:27 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 542E121F9901 for ; Wed, 2 Oct 2013 21:04:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAETsTFJ20epE/2dsb2JhbAANTMVNgTaDGQEBAQQ4GyUBDAQLEQQBAQEJFggHCQMCAQIBNAkIBg0BBQIBAbJwkymPUQcGhB0DrTY Received: from ppp118-209-234-68.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.234.68]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Oct 2013 13:34:02 +0930 Message-ID: <524CECAC.5040107@nteczone.com> Date: Thu, 03 Oct 2013 14:03:56 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 04:04:34 -0000 Hello Christer, When I used the term "logical" capture it was really just to illustrate that an MCU does not need to slavishly copy the source captures. It can provide any sort of processing to these source captures and then advertise what it wants. Regards, Christian On 2/10/2013 5:54 PM, Christer Holmberg wrote: > Hi, > > I guess I've missed the "logical capture" concept. If we want to use that, I think we need to have a clear description and definition of what it means, and when it is used. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: 2. lokakuuta 2013 3:57 > To: Christer Holmberg > Cc: clue@ietf.org > Subject: Re: [clue] MCC with CSE > > Hello Christer, > > ..snip.. > >>> [CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right. >>> To capture the metadata for each "site" in an MCC: >>> >>> CaptureScene1(Description=SiteA,VC1) >>> CaptureScene2(Description=SiteB,VC2) >>> CaptrueScene3(Description=SiteC,VC3) >>> etc. >>> MCC(VC1,VC2,VC3,etc.) >> That works fine if the MCU always uses the same VC of each site to create the MCC. > [CNG] VC1 is just a logical representation, it doesn't have to be one of the source captures that the MCU received. >> But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site. > [CNG] No it doesn't. The VC in this case is only used as a logical entity to represent the site. There's no capture encoding. The MCU may wish to advertise all the source captures or produce its own captures based on the source information. >> So, again, I am not really interested in which VC of each site is used to create the MCC, I am only interested to know that it represents the active speaker, and/or the slides, etc. >> >> Maybe something like: >> >> CaptureSceneMCU(Description=SiteA,SiteB,SiteC, MCC1) >> MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker > [CNG] I guess you mean MCC1() in the 2nd line? It could work although "Description" currently doesn't allow multiple values and is an unstructured string so the consumer may not understand that there are essentially multiple values. >> > regards, Christian > From Christian.Groves@nteczone.com Wed Oct 2 22:31:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7368321F9FA4 for ; Wed, 2 Oct 2013 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx-YMSucYLXH for ; Wed, 2 Oct 2013 22:31:10 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id B665C21F9E9D for ; Wed, 2 Oct 2013 22:31:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADYATVJ20epE/2dsb2JhbAANTMVKgTSDGgEBBDgbJRELIRYPCQMCAQIBRRMIAQGyZ5Mnj1iEIwOtNg Received: from ppp118-209-234-68.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.234.68]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Oct 2013 15:01:01 +0930 Message-ID: <524D010F.3030600@nteczone.com> Date: Thu, 03 Oct 2013 15:30:55 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> <5245FBA5.6060809@nteczone.com> <5249AA02.3020703@cisco.com> <524A2C70.6000106@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D603450392@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D603450392@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 05:31:22 -0000 Hello ..snip.. >>>>> One downside to this approach is that every change the MCU makes in >>>>> how it assigns contributing VCs to an MCC (e.g. make a switch based >>>>> on current talker) could result in the consumer renderer needing to >>>>> change how it maps decoder output to display locations. I need to >>>>> think more about if this would really be a problem or not. >>>> [CNG] For this switching case I would think that a consumer would use >>>> the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would >>>> always present the active speaker from the list of VC using the same >>>> co-ordinates. Or are you talking about switching the positions in a >>>> composed MCC? > [Duckworth, Mark] I was not talking about a composed MCC. I think you are saying in this example that MCC4 is the most active speaker, MCC5 is the next most active speaker, etc. and the MCU switches in the appropriate original VC to make this policy happen, is that right? [CNG] Yes > I'm thinking of the case where the MCU is switching multiple VCs from the same originating endpoint together, like the "site switch" policy we have talked about. [CNG] CapScene8 is an example of this. > So maybe MCC4, MCC5, and MCC6 contain the three VCs from the active speaker that is in a three-camera room. [CNG] You would could use the syntax of CapScene8 plus a policy "ActiveSpeaker". > Then MCC7 contains the next most active speaker from another room, and MCC8-10 might be the third most active speaker from another three-camera room. And this mapping of which MCCs are showing portions of the same room can change often. [CNG] I'm not sure that we're on the same page here, is it something you could illustrate through example syntax?... Capture8 synchronises between MCC1, MCC2 and MCC3. If one of the single source capture sites (i.e.VC13,VC14,V15) become active this is shown as part of MCC2, the encoding of MCC1 and MCC3 would be blank. > I thought using multiple scenes with smaller CSEs could help simplify this, which you agreed with below, so I guess we should focus on that rather than this CapScene9 example which has a large CSE with 9 > MCCs in it. [CNG] I agreed it would be possible to use multiple CSEs to illustrate different "scenes". Its possible to offer multiple smaller CSEs or large ones. I think it depends on what the MCU wants to express/provide. > But Rob might disagree, so more questions below. >>> [RH] My issue with using the spatial coordinates of the MCC is that it >>> requires the MCU to anticipate the rendering desires of the endpoint, >>> as the MCU will need to advertise MCCs with spatial coordinates that >>> allow the endpoint to do what it wants to do. My concern has always >>> been that this may lead to huge numbers of MCCs and capture scene >>> entries if the MCU is trying to anticipate potential layouts by the >>> endpoint. >> [CNG] A consumer can choose to render how it sees fit. The spatial >> information is a guide. If the MCU advertises a switched MCC showing the >> most active speaker in the left position and a MCC showing the second most >> active speaker in the right position there's nothing stopping the consumer >> from swapping the positions when rendering. I don't think its up to an >> Advertiser to provide every conceivable spatial layout. > [Duckworth, Mark] With the multiple scenes approach, I see the MCU trying to anticipate the consumer's rendering desire only at a very high level. That is the MCU can provide small sets of captures in a CSE advertised by the MCU, while keeping VCs together in the same MCU CSE that originally come from the same scene from the original endpoint provider. [CNG] I agree > > [Duckworth, Mark] Rob, are you suggesting a better approach is for the renderer to use just the spatial information of the original VCs, and not try to use MCU-generated spatial information about the MCCs? Basically following the idea above - "The consumer should have enough information to do this if the MCU provides all the original spatial information from each endpoint in the advertisement" > > From christer.holmberg@ericsson.com Wed Oct 2 23:58:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D6021F8F4A for ; Wed, 2 Oct 2013 23:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwRsHPms7rtb for ; Wed, 2 Oct 2013 23:57:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 976F421F9E94 for ; Wed, 2 Oct 2013 23:57:19 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-89-524d1545e3a5 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0B.E3.03802.5451D425; Thu, 3 Oct 2013 08:57:09 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 08:57:06 +0200 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJwAJNF4AAB11LgAAgl6UgAAQPZIwAB+AXYAAEnQu0AAmXLIAAAosKIA= Date: Thu, 3 Oct 2013 06:57:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B2C81@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> <524CECAC.5040107@nteczone.com> In-Reply-To: <524CECAC.5040107@nteczone.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra6PqG+QwZcnnBZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4MqYPGUDe8Fh0Yqr366yNTDOFuxi5OCQEDCR ONUQ0cXICWSKSVy4t56ti5GLQ0jgMKPExZ45UM5iRokvl1+ygzSwCVhIdP/TBjFFgHrnn9UE 6WUWUJb42rCJCcQWFlCQOLe1hwXEFhFQlPj7bQc7yBgRgXmMEjsm3mUHSbAIqEisfX0bzOYV 8JU4/mgqI8SuOWwSJ+5tZQNJcAroSNzo3g82lRHouu+n1jBBbBOX+HDwOjPE1QISS/ach7JF JV4+/scKYStJ/NhwiQWiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPYLCRjZyFpmYWkZRaS lgWMLKsY2XMTM3PSy402MQJj5OCW36o7GO+cEznEKM3BoiTO++Gtc5CQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGRo0XU70qayIvH3Zobiw6ZLqjmflG8cG30zKv7brw/THDVf70a4vWP//1 rrpq8bkDy19PVjMJnXjo066As/qnW34ECPkydhpe1jSa1iPUHi2/YdKX4lMdf555PJy9aX5E ckp6SkbgluvNj5au1Xtxpu7y/V6DG+HL5CbaVM+1i2MV1ktrO3xjww4lluKMREMt5qLiRAAi RMAkXwIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 06:58:09 -0000 Hi Christian, >When I used the term "logical" capture it was really just to illustrate th= at an MCU does not need to slavishly copy the source captures. It can provi= de any sort of processing to these source captures and then advertise what = it wants. That is fine. My point is that we should not add some "dummy" VC. If we see a need for "l= ogical" VCs, that e.g. represent a whole site, rather than an individual VC= of that site, it should be possible to indicate so. Regards, Christer Regards, Christian On 2/10/2013 5:54 PM, Christer Holmberg wrote: > Hi, > > I guess I've missed the "logical capture" concept. If we want to use that= , I think we need to have a clear description and definition of what it mea= ns, and when it is used. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: 2. lokakuuta 2013 3:57 > To: Christer Holmberg > Cc: clue@ietf.org > Subject: Re: [clue] MCC with CSE > > Hello Christer, > > ..snip.. > >>> [CNG]"Site" information is related to the "CaptureScene" level. So to a= have a "site/scene" level information at the capture level doesn't seem ri= ght. >>> To capture the metadata for each "site" in an MCC: >>> >>> CaptureScene1(Description=3DSiteA,VC1) >>> CaptureScene2(Description=3DSiteB,VC2) >>> CaptrueScene3(Description=3DSiteC,VC3) >>> etc. >>> MCC(VC1,VC2,VC3,etc.) >> That works fine if the MCU always uses the same VC of each site to creat= e the MCC. > [CNG] VC1 is just a logical representation, it doesn't have to be one of = the source captures that the MCU received. >> But, if the MCC e.g. contains the active speaker of a site, the CaptureS= cene descriptions would need to include all VCs that might represent the ac= tive speaker of a given site. > [CNG] No it doesn't. The VC in this case is only used as a logical entity= to represent the site. There's no capture encoding. The MCU may wish to ad= vertise all the source captures or produce its own captures based on the so= urce information. >> So, again, I am not really interested in which VC of each site is used t= o create the MCC, I am only interested to know that it represents the activ= e speaker, and/or the slides, etc. >> >> Maybe something like: >> >> CaptureSceneMCU(Description=3DSiteA,SiteB,SiteC, MCC1)=20 >> MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker > [CNG] I guess you mean MCC1() in the 2nd line? It could work although "De= scription" currently doesn't allow multiple values and is an unstructured s= tring so the consumer may not understand that there are essentially multipl= e values. >> > regards, Christian > From Christian.Groves@nteczone.com Thu Oct 3 00:07:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFEB21F9FC8 for ; Thu, 3 Oct 2013 00:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tbP7pmo5ZRb for ; Thu, 3 Oct 2013 00:07:08 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3670F21F9FD7 for ; Thu, 3 Oct 2013 00:06:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALUWTVJ20epE/2dsb2JhbAANTcVKgTWDGQEBAQQ4GyUBDAQLEQQBAQEJFggHCQMCAQIBNAkIBg0BBQIBAbIFky2PUQcGhB0DrTY Received: from ppp118-209-234-68.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.234.68]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Oct 2013 16:36:41 +0930 Message-ID: <524D177B.9050303@nteczone.com> Date: Thu, 03 Oct 2013 17:06:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> <524CECAC.5040107@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B2C81@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B2C81@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 07:07:19 -0000 Hello Christer, Its not a "dummy" VC. A MCU can take two captures VC1 and VC2 (i.e. two streams) from a site and turn this into a VC3 (i.e. a single stream providing a signal video with the picture and slides). In this case the MCU has chosen to represent the site through a single VC and not through the source captures. Christian On 3/10/2013 4:57 PM, Christer Holmberg wrote: > Hi Christian, > >> When I used the term "logical" capture it was really just to illustrate that an MCU does not need to slavishly copy the source captures. It can provide any sort of processing to these source captures and then advertise what it wants. > That is fine. > > My point is that we should not add some "dummy" VC. If we see a need for "logical" VCs, that e.g. represent a whole site, rather than an individual VC of that site, it should be possible to indicate so. > > Regards, > > Christer > > > > > Regards, Christian > > On 2/10/2013 5:54 PM, Christer Holmberg wrote: >> Hi, >> >> I guess I've missed the "logical capture" concept. If we want to use that, I think we need to have a clear description and definition of what it means, and when it is used. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: 2. lokakuuta 2013 3:57 >> To: Christer Holmberg >> Cc: clue@ietf.org >> Subject: Re: [clue] MCC with CSE >> >> Hello Christer, >> >> ..snip.. >> >>>> [CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right. >>>> To capture the metadata for each "site" in an MCC: >>>> >>>> CaptureScene1(Description=SiteA,VC1) >>>> CaptureScene2(Description=SiteB,VC2) >>>> CaptrueScene3(Description=SiteC,VC3) >>>> etc. >>>> MCC(VC1,VC2,VC3,etc.) >>> That works fine if the MCU always uses the same VC of each site to create the MCC. >> [CNG] VC1 is just a logical representation, it doesn't have to be one of the source captures that the MCU received. >>> But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site. >> [CNG] No it doesn't. The VC in this case is only used as a logical entity to represent the site. There's no capture encoding. The MCU may wish to advertise all the source captures or produce its own captures based on the source information. >>> So, again, I am not really interested in which VC of each site is used to create the MCC, I am only interested to know that it represents the active speaker, and/or the slides, etc. >>> >>> Maybe something like: >>> >>> CaptureSceneMCU(Description=SiteA,SiteB,SiteC, MCC1) >>> MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker >> [CNG] I guess you mean MCC1() in the 2nd line? It could work although "Description" currently doesn't allow multiple values and is an unstructured string so the consumer may not understand that there are essentially multiple values. >> regards, Christian >> > From christer.holmberg@ericsson.com Thu Oct 3 00:18:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F02721F9A6D for ; Thu, 3 Oct 2013 00:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.884 X-Spam-Level: X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UHEMDTH4tiW for ; Thu, 3 Oct 2013 00:18:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 553A221F9EE1 for ; Thu, 3 Oct 2013 00:17:40 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-51-524d1a12482b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8E.87.03802.21A1D425; Thu, 3 Oct 2013 09:17:38 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Thu, 3 Oct 2013 09:17:38 +0200 From: Christer Holmberg To: Christian Groves Thread-Topic: VS: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJwAJNF4AAB11LgAAgl6UgAAQPZIwAB+AXYAAEnQu0AAmXLIAAAosKID//+GmgP//3AhQ Date: Thu, 3 Oct 2013 07:17:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4B2D23@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> <524CECAC.5040107@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B2C81@ESESSMB209.ericsson.se> <524D177B.9050303@nteczone.com> In-Reply-To: <524D177B.9050303@nteczone.com> Accept-Language: en-US Content-Language: fi-FI 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+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvra6QlG+Qwf1LuhZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4MrYMOkac8FeqYp3B6YwNzB2inYxcnJICJhI nHo9gx3CFpO4cG89WxcjF4eQwGFGiS3v1zBCOIsZJdZsmMnaxcjBwSZgIdH9TxvEFAFqnn9W E6SXWUBZ4mvDJiYQW1hAReLK1iYWEFtEQFVi8sw+sDEiAqsYJdZPmMkGkmABKura2gdWxCvg K3HrTQfUriZ2iSf75jOCLOAU0JG48sIdpIYR6Ljvp9YwQSwTl/hw8DozxNECEkv2nIeyRSVe Pv7HCmErSfzYcIkFol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2chaZmFpGUWkpYF jCyrGNlzEzNz0suNNjECY+Tglt+qOxjvnBM5xCjNwaIkzvvhrXOQkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsaWhw7lbmzKVU1ut89odj1999o5puq/2LGVT6z/L+Ock51/aJ+O2wrb5vvP Rc6Lsya5qMxsl1ukVVN8faPWOkWhc55T9716V84UnmGc+63+99GEdkGdh/r3ym1uMUsmyBg7 qW3IrS4MXscrc+LkRFWJG9v3M+e90by0y9zzkMXO2XLehxPmr1JiKc5INNRiLipOBABbSwIm XwIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 07:18:19 -0000 Hi, > Its not a "dummy" VC. A MCU can take two captures VC1 and VC2 (i.e. two s= treams) from a site and turn this into a VC3 (i.e. a single stream providin= g a signal=20 > video with the picture and slides). In this case the MCU has chosen to re= present the site through a single VC and not through the source captures. In that case, aren't we talking about an MCC? In other words: the MCU advertises an MCC, which includes a number of MCCs = - each representing a site. Regards, Christer On 3/10/2013 4:57 PM, Christer Holmberg wrote: > Hi Christian, > >> When I used the term "logical" capture it was really just to illustrate = that an MCU does not need to slavishly copy the source captures. It can pro= vide any sort of processing to these source captures and then advertise wha= t it wants. > That is fine. > > My point is that we should not add some "dummy" VC. If we see a need for = "logical" VCs, that e.g. represent a whole site, rather than an individual = VC of that site, it should be possible to indicate so. > > Regards, > > Christer > > > > > Regards, Christian > > On 2/10/2013 5:54 PM, Christer Holmberg wrote: >> Hi, >> >> I guess I've missed the "logical capture" concept. If we want to use tha= t, I think we need to have a clear description and definition of what it me= ans, and when it is used. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: 2. lokakuuta 2013 3:57 >> To: Christer Holmberg >> Cc: clue@ietf.org >> Subject: Re: [clue] MCC with CSE >> >> Hello Christer, >> >> ..snip.. >> >>>> [CNG]"Site" information is related to the "CaptureScene" level. So to = a have a "site/scene" level information at the capture level doesn't seem r= ight. >>>> To capture the metadata for each "site" in an MCC: >>>> >>>> CaptureScene1(Description=3DSiteA,VC1) >>>> CaptureScene2(Description=3DSiteB,VC2) >>>> CaptrueScene3(Description=3DSiteC,VC3) >>>> etc. >>>> MCC(VC1,VC2,VC3,etc.) >>> That works fine if the MCU always uses the same VC of each site to crea= te the MCC. >> [CNG] VC1 is just a logical representation, it doesn't have to be one of= the source captures that the MCU received. >>> But, if the MCC e.g. contains the active speaker of a site, the Capture= Scene descriptions would need to include all VCs that might represent the a= ctive speaker of a given site. >> [CNG] No it doesn't. The VC in this case is only used as a logical entit= y to represent the site. There's no capture encoding. The MCU may wish to a= dvertise all the source captures or produce its own captures based on the s= ource information. >>> So, again, I am not really interested in which VC of each site is used = to create the MCC, I am only interested to know that it represents the acti= ve speaker, and/or the slides, etc. >>> >>> Maybe something like: >>> >>> CaptureSceneMCU(Description=3DSiteA,SiteB,SiteC, MCC1)=20 >>> MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker >> [CNG] I guess you mean MCC1() in the 2nd line? It could work although "D= escription" currently doesn't allow multiple values and is an unstructured = string so the consumer may not understand that there are essentially multip= le values. >> regards, Christian >> > From Christian.Groves@nteczone.com Thu Oct 3 00:47:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D2521F9AC4 for ; Thu, 3 Oct 2013 00:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT7UT+0GmapW for ; Thu, 3 Oct 2013 00:46:53 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6412521F9DAF for ; Thu, 3 Oct 2013 00:44:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAB8gTVJ20epE/2dsb2JhbAANTcVKgTWDGQEBAQQ4GyYMBAsRBAEBAQkeBw8CNQkIBg0BBQIBAbFvky6PUQcGhB0DrTY Received: from ppp118-209-234-68.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.234.68]) by ipmail06.adl6.internode.on.net with ESMTP; 03 Oct 2013 17:14:35 +0930 Message-ID: <524D205F.30802@nteczone.com> Date: Thu, 03 Oct 2013 17:44:31 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> <524A2EFF.9040908@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B0C52@ESESSMB209.ericsson.se> <524B6F63.8060108@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B1B8B@ESESSMB209.ericsson.se> <524CECAC.5040107@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B2C81@ESESSMB209.ericsson.se> <524D177B.9050303@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4B2D23@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4B2D23@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 07:47:00 -0000 Hello Christer, Yes you can use an MCC. However the MCU would only use an MCC if it wanted to maintain information about the source captures or provide some information about the multiple content i.e. policy. Otherwise the MCU can simply use a normal VC as per the example below. Christian On 3/10/2013 5:17 PM, Christer Holmberg wrote: > Hi, > >> Its not a "dummy" VC. A MCU can take two captures VC1 and VC2 (i.e. two streams) from a site and turn this into a VC3 (i.e. a single stream providing a signal >> video with the picture and slides). In this case the MCU has chosen to represent the site through a single VC and not through the source captures. > In that case, aren't we talking about an MCC? > > In other words: the MCU advertises an MCC, which includes a number of MCCs - each representing a site. > > Regards, > > Christer > > > > > On 3/10/2013 4:57 PM, Christer Holmberg wrote: >> Hi Christian, >> >>> When I used the term "logical" capture it was really just to illustrate that an MCU does not need to slavishly copy the source captures. It can provide any sort of processing to these source captures and then advertise what it wants. >> That is fine. >> >> My point is that we should not add some "dummy" VC. If we see a need for "logical" VCs, that e.g. represent a whole site, rather than an individual VC of that site, it should be possible to indicate so. >> >> Regards, >> >> Christer >> >> >> >> >> Regards, Christian >> >> On 2/10/2013 5:54 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I guess I've missed the "logical capture" concept. If we want to use that, I think we need to have a clear description and definition of what it means, and when it is used. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: 2. lokakuuta 2013 3:57 >>> To: Christer Holmberg >>> Cc: clue@ietf.org >>> Subject: Re: [clue] MCC with CSE >>> >>> Hello Christer, >>> >>> ..snip.. >>> >>>>> [CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right. >>>>> To capture the metadata for each "site" in an MCC: >>>>> >>>>> CaptureScene1(Description=SiteA,VC1) >>>>> CaptureScene2(Description=SiteB,VC2) >>>>> CaptrueScene3(Description=SiteC,VC3) >>>>> etc. >>>>> MCC(VC1,VC2,VC3,etc.) >>>> That works fine if the MCU always uses the same VC of each site to create the MCC. >>> [CNG] VC1 is just a logical representation, it doesn't have to be one of the source captures that the MCU received. >>>> But, if the MCC e.g. contains the active speaker of a site, the CaptureScene descriptions would need to include all VCs that might represent the active speaker of a given site. >>> [CNG] No it doesn't. The VC in this case is only used as a logical entity to represent the site. There's no capture encoding. The MCU may wish to advertise all the source captures or produce its own captures based on the source information. >>>> So, again, I am not really interested in which VC of each site is used to create the MCC, I am only interested to know that it represents the active speaker, and/or the slides, etc. >>>> >>>> Maybe something like: >>>> >>>> CaptureSceneMCU(Description=SiteA,SiteB,SiteC, MCC1) >>>> MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker >>> [CNG] I guess you mean MCC1() in the 2nd line? It could work although "Description" currently doesn't allow multiple values and is an unstructured string so the consumer may not understand that there are essentially multiple values. >>> regards, Christian >>> > From jonathan@vidyo.com Thu Oct 3 08:09:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ADD11E80F8 for ; Thu, 3 Oct 2013 08:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQijFj8WPbwZ for ; Thu, 3 Oct 2013 08:09:09 -0700 (PDT) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id 875E211E80EC for ; Thu, 3 Oct 2013 07:56:34 -0700 (PDT) X-Note-AR-ScanTimeLocal: 10/3/2013 10:56:30 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-150/SG:5 10/3/2013 10:56:09 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.950368 p=-0.971544 Source White X-Signature-Violations: 0-0-0-32767-c X-Note-419: 31.2006 ms. Fail:1 Chk:1347 of 1347 total X-Note: SCH-CT/SI:1-1347/SG:1 10/3/2013 10:56:29 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNKNOWN->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G340 G341 G342 G343 G347 G348 G455 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 37531993; Thu, 03 Oct 2013 10:56:29 -0400 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 09:56:28 -0500 From: Jonathan Lennox To: "DRAGE, Keith (Keith)" Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: AQHOv3oWJ1Ix+kZPRoO+ExTufi0unJnhdbpQgAHwnwA= Date: Thu, 3 Oct 2013 14:56:28 +0000 Message-ID: <9EFD19D8-CE2F-41B8-91E4-B156379066D4@vidyo.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.99.12] Content-Type: multipart/alternative; boundary="_000_9EFD19D8CE2F41B891E4B156379066D4vidyocom_" MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 15:09:23 -0000 --_000_9EFD19D8CE2F41B891E4B156379066D4vidyocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You're running into the problem of the lack of scoping parentheses in natur= al language. It's not (non-CLUE) enabled, it's non-(CLUE enabled). Would "non-CLUE-enabled" (with the extra hyphen) be clearer? On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)" > wrote: If you don=92t have a telephone, you don=92t suddenly have a =93non-telepho= ne=94, on which you make your =93non-calls=94. You need to apply the negation to the right word, and it is not CLUE that i= s subject to the negation. Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 02 October 2013 15:17 To: DRAGE, Keith (Keith) Cc: Paul Coverdale; CLUE Subject: Re: [clue] Its not "legacy", its ??? "non-CLUE enabled" means the endpoint does not support the CLUE protocol (a= t all) or the endpoint is not using the CLUE protocol for whatever reason (= e.g., fallback case) I think the "non-CLUE" is more in line with the original implication of the= term "legacy". Mary . On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) > wrote: Just to add a pedantic point, I am not sure what a =93non-CLUE=94 is. What = we have is something where CLUE does not exist, not the creation of some ot= her concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to app= ly the negation to the =93enabled=94 which is something like =93disabled=94= , =93unenabled=94 or whatever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_9EFD19D8CE2F41B891E4B156379066D4vidyocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <039C63D3B010694ABEFB7F8895EEF869@vidyo.com> Content-Transfer-Encoding: quoted-printable
You're running into the problem of the lack of scoping parentheses in = natural language.  It's not (non-CLUE) enabled, it's non-(CLUE enabled= ).

Would "non-CLUE-enabled" (with the extra hyphen) be clearer?=

On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.co= m>
 wrote:

If you don=92t have a telephone, you d= on=92t suddenly have a =93non-telephone=94, on which you make your =93non-c= alls=94.

 

You need to apply the negation to the = right word, and it is not CLUE that is subject to the negation.<= /span>

 

Keith

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 02 October 2013 15:17<= br> To: DRAGE, Keith (Keith)
Cc: Paul Coverdale; CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

"non-CLUE enabled" means the endpoint does not support th= e CLUE protocol (at all) or the endpoint is not using the CLUE protocol for= whatever reason (e.g., fallback case)

 

I think the "non-CLUE" is more in line with the original = implication of the term "legacy".  =

 

Mary .

 

On Wed, Oct= 2, 2013 at 9:12 AM, DRAGE, K= eith (Keith) <keith.drage@alcatel-lucent.com> wrote:=

Just to add a pedantic point, I am not sure what a =93non-CLUE= =94 is. What we have is something where CLUE does not exist, not the creation of some othe= r concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to apply= the negation to the =93enabled=94 which is something like =93disabled=94, = =93unenabled=94 or whatever.

 

Keith

 

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Tahoma"> clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
Cc: CLUE<= /o:p>


Subject: Re: [clue] Its not = "legacy", its ???

 

It is a fine line.  I personally have a preference for "= non-CLUE enabled".   I really don't think we'll be using that in too many places in the documents that it's too much typing.  = If someone thinks that's the case, perhaps we use "clueless" in t= he docs until we're ready to ship them out of the WG and then just do a glo= bal change.  As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right sema= ntics and really isn't too much of a mouthful to say either.

 

Mary. 

 

On Wed, Oct= 2, 2013 at 8:35 AM, Paul Cov= erdale <cove= rdale@sympatico.ca> wrote:

I thought the proposal of "clueless' was just a joke when I f= irst saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original Message-----
>From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

 

 

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

--_000_9EFD19D8CE2F41B891E4B156379066D4vidyocom_-- From keith.drage@alcatel-lucent.com Thu Oct 3 10:20:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D00211E8112 for ; Thu, 3 Oct 2013 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paeQM1Z8OMQf for ; Thu, 3 Oct 2013 10:20:27 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B15D021E80CA for ; Thu, 3 Oct 2013 10:00:05 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r93H00El001024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Oct 2013 12:00:02 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r93H00Br030979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Oct 2013 19:00:00 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 3 Oct 2013 18:59:59 +0200 From: "DRAGE, Keith (Keith)" To: Jonathan Lennox Thread-Topic: [clue] Its not "legacy", its ??? Thread-Index: Ac6+7vMUJ1Ix+kZPRoO+ExTufi0unJnhdbpQgAHwnwCZ4JQi4A== Date: Thu, 3 Oct 2013 16:59:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0AF75E@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9EFD19D8-CE2F-41B8-91E4-B156379066D4@vidyo.com> In-Reply-To: <9EFD19D8-CE2F-41B8-91E4-B156379066D4@vidyo.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: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B0AF75EFR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 17:20:39 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B0AF75EFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable English doesn't work that way. The only way to do what you are doing is to = say "CLUE non-enabled" or probably more correctly "CLUE not enabled". Keith ________________________________ From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: 03 October 2013 15:56 To: DRAGE, Keith (Keith) Cc: Mary Barnes; CLUE Subject: Re: [clue] Its not "legacy", its ??? You're running into the problem of the lack of scoping parentheses in natur= al language. It's not (non-CLUE) enabled, it's non-(CLUE enabled). Would "non-CLUE-enabled" (with the extra hyphen) be clearer? On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)" > wrote: If you don't have a telephone, you don't suddenly have a "non-telephone", o= n which you make your "non-calls". You need to apply the negation to the right word, and it is not CLUE that i= s subject to the negation. Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 02 October 2013 15:17 To: DRAGE, Keith (Keith) Cc: Paul Coverdale; CLUE Subject: Re: [clue] Its not "legacy", its ??? "non-CLUE enabled" means the endpoint does not support the CLUE protocol (a= t all) or the endpoint is not using the CLUE protocol for whatever reason (= e.g., fallback case) I think the "non-CLUE" is more in line with the original implication of the= term "legacy". Mary . On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) > wrote: Just to add a pedantic point, I am not sure what a "non-CLUE" is. What we h= ave is something where CLUE does not exist, not the creation of some other = concept of a "non-CLUE" to complement a "CLUE". You want to apply the negat= ion to the "enabled" which is something like "disabled", "unenabled" or wha= tever. Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 02 October 2013 14:57 To: Paul Coverdale Cc: CLUE Subject: Re: [clue] Its not "legacy", its ??? It is a fine line. I personally have a preference for "non-CLUE enabled". = I really don't think we'll be using that in too many places in the docume= nts that it's too much typing. If someone thinks that's the case, perhaps = we use "clueless" in the docs until we're ready to ship them out of the WG = and then just do a global change. As I've said before for XCON, we do use = the term "non-XCON enabled" which I think has the right semantics and reall= y isn't too much of a mouthful to say either. Mary. On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: I thought the proposal of "clueless' was just a joke when I first saw it, but apparently not. I think this term will just invite ridicule. It's a bit of a mouthful, but = I would suggest "non-CLUE" equipped". But if you insist on using "clueless", at least hyphenate it (clue-less). ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Tuesday, October 01, 2013 5:40 PM >To: clue@ietf.org >Subject: Re: [clue] Its not "legacy", its ??? > >On 10/1/13 12:45 PM, Robert Hansen wrote: >> I am personally very fond of 'CLUEless' :) > >One of the reasons I liked the name "clue" for the wg was because it >gave us an excuse to use "clueless" and "clueful". However they do have >the feel of "informal" usage - a bit odd for formal use. (But I can get >over that.) > > Thanks, > Paul > >> Rob >> >> On 01/10/2013 17:22, Paul Kyzivat wrote: >>> Mary, >>> >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss what >>> word to use - that we could do that on the list. >>> >>> I agree with you, I also think "legacy" has the wrong connotation for >>> what we mean, so I would like to find a better term. I have no ideas >>> that I love, but a couple that I could live with: "non-clue", >"clueless". >>> >>> Thanks, >>> Paul >>> >>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>> would really, really like to get away from the term "legacy" - the >>>> English language definition of "legacy" is not correct. CLUE isn't >>>> superseding any functionality of current SIP endpoints. It's adding >>>> additional functionality. I would much rather select something like >>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>> about the length of a more appropriate alternative term. >>>> >>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>> slightly more appropriate since it's a different architecture and >>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>> CLUE is, so any suggestion that it's replacing any current SIP >>>> functionality isn't correct. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>> >> wrote: >>>> >>>> You can find Christer's slides for today at: >>>> >>>> >>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>> eam/CLUE_Legacy___1oct13.pptx >>>> >>>> >>>> >>>> >>> /CLUE_Legacy_1oct13.pptx> >>>> >>>> >>>> >>>> See you shortly. >>>> >>>> Paul >>>> _________________________________________________ >>>> clue mailing list >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/__listinfo/clue >>>> >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_949EF20990823C4C85C18D59AA11AD8B0AF75EFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

English doesn’t work that way. T= he only way to do what you are doing is to say “CLUE non-enabled̶= 1; or probably more correctly “CLUE not enabled”.

 

Keith

 

From: Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 03 October 2013 15:56<= br> To: DRAGE, Keith (Keith)
Cc: Mary Barnes; CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

You're running into the problem of the lack of scoping parentheses = in natural language.  It's not (non-CLUE) enabled, it's non-(CLUE enab= led).

 

Would "non-CLUE-enabled" (with the extra hyphen) be clear= er?

 

On Oct= 2, 2013, at 10:45 AM, "= DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>

 wrote:



If you don’t have a telephone, y= ou don’t suddenly have a “non-telephone”, on which you ma= ke your “non-calls”.

 =

You need to apply the negation to the = right word, and it is not CLUE that is subject to the negation.

 =

Keith<= /o:p>

 =

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 02 October 2013 15:17<= br> To: DRAGE, Keith (Keith)
Cc: Paul Coverdale; CLUE
Subject: Re: [clue] Its not = "legacy", its ???

 

"non-CLUE enabled" means the endpoint does not support th= e CLUE protocol (at all) or the endpoint is not using the CLUE protocol for= whatever reason (e.g., fallback case)

 

I think the "non-CLUE" is more in line with the original = implication of the term "legacy".  <= /span>

 

Mary .

 

On Wed, Oct 2= , 2013 at 9:12 AM, DRAGE, Keith (Keith) <= ;keith.= drage@alcatel-lucent.com> wrote:

Just to add a pedantic point, I am not sure what a “non-C= LUE” is. What we have is something where CLUE does not exist, not the creation of some othe= r concept of a “non-CLUE” to complement a “CLUE”. Y= ou want to apply the negation to the “enabled” which is somethi= ng like “disabled”, “unenabled” or whatever.=

 

Keith

 

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Tahoma"> clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
Cc: CLUE=


Subject: Re: [clue] Its not = "legacy", its ???

 

It is a fine line.  I personally have a preference for "= non-CLUE enabled".   I really don't think we'll be using that in too many places in the documents that it's too much typing.  = If someone thinks that's the case, perhaps we use "clueless" in t= he docs until we're ready to ship them out of the WG and then just do a glo= bal change.  As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right sema= ntics and really isn't too much of a mouthful to say either.

 

Mary. 

 

On Wed, Oct 2= , 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.= ca> wrote:

I thought the proposal of "clueless' was just a joke when I f= irst saw it,
but apparently not.

I think this term will just invite ridicule. It's a bit of a mouthful, but = I
would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
at least hyphenate it (clue-less).

...Paul


>-----Original Message-----
>From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of=

>Paul Kyzivat
>Sent: Tuesday, October 01, 2013 5:40 PM
>To: clue@ietf.org
>Subject: Re: [clue] Its not "legacy", its ???
>

>On 10/1/13 12:45 PM, Robert Hansen wrote:
>> I am personally very fond of 'CLUEless' :)
>
>One of the reasons I liked the name "clue" for the wg was bec= ause it
>gave us an excuse to use "clueless" and "clueful". = However they do have
>the feel of "informal" usage - a bit odd for formal use. (But= I can get
>over that.)
>
>       Thanks,
>       Paul
>
>> Rob
>>
>> On 01/10/2013 17:22, Paul Kyzivat wrote:
>>> Mary,
>>>
>>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discuss w= hat
>>> word to use - that we could do that on the list.
>>>
>>> I agree with you, I also think "legacy" has the wron= g connotation for
>>> what we mean, so I would like to find a better term. I have no= ideas
>>> that I love, but a couple that I could live with: "non-cl= ue",
>"clueless".
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 10/1/13 10:26 AM, Mary Barnes wrote:
>>>> I'm in another meeting so unfortunately cannot attend toda= y.  But, I
>>>> would really, really like to get away from the term "= legacy" -  the
>>>> English language definition of "legacy" is not c= orrect. CLUE isn't
>>>> superseding any functionality of current SIP endpoints. &n= bsp;It's adding
>>>> additional functionality. I would much rather select somet= hing like
>>>> "non-Clue enabled endpoint".   We can short= en if folks are concerned
>>>> about the length of a more appropriate alternative term. >>>>
>>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
>>>> slightly more appropriate since it's a different architect= ure and
>>>> entirely new application - i.e., it isn't based on RFC 326= 1, but
>>>> CLUE is, so any suggestion that it's replacing any current= SIP
>>>> functionality isn't correct.
>>>>
>>>> Regards,
>>>> Mary.
>>>>
>>>>
>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>
>>>>     You can find Christer's slides for today at:=
>>>>
>>>>

>>>> /CLUE_Legacy_1oct13.pptx>
>>>>
>>>>
>>>>
>>>>     See you shortly.
>>>>
>>>>              Paul
>>>>     ____________________________________________= _____
>>>>     clue mailing list
>>>>     clue@ietf.org <mailto:clue@ietf.org>
>>>>     https://www.ietf.org/mailman/__listinfo/clue=
>>>>     <https://www.ietf.org/mailman/listinfo/clue= >
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/clue
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue=

 

 

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

 

--_000_949EF20990823C4C85C18D59AA11AD8B0AF75EFR712WXCHMBA11zeu_-- From pkyzivat@alum.mit.edu Thu Oct 3 12:12:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30EE21F9A4A for ; Thu, 3 Oct 2013 12:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMeuiQJf9bjM for ; Thu, 3 Oct 2013 12:12:04 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 13F2521F9A98 for ; Thu, 3 Oct 2013 12:01:58 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta08.westchester.pa.mail.comcast.net with comcast id YcUr1m0010SCNGk58j1q8X; Thu, 03 Oct 2013 19:01:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id Yj1p1m01N3ZTu2S3Vj1qlV; Thu, 03 Oct 2013 19:01:50 +0000 Message-ID: <524DBF1C.4040106@alum.mit.edu> Date: Thu, 03 Oct 2013 15:01:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524ACBD0.9040401@alum.mit.edu> <524AF6E0.2070205@alum.mit.edu> <524AFC21.7070106@cisco.com> <524B414C.2030406@alum.mit.edu> <949EF20990823C4C85C18D59AA11AD8B0AE8A1@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B0AE960@FR712WXCHMBA11.zeu.alcatel-lucent.com> <9EFD19D8-CE2F-41B8-91E4-B156379066D4@vidyo.com> <949EF20990823C4C85C18D59AA11AD8B0AF75E@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0AF75E@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380826910; bh=gmX8U12J4KBd025Tact2TXnZfnyrM3Ba8TpVQTaAvZE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=N+r2kj4oZsQHFaCbE1uZcL4VrkeiR5X9aYZOgU4kGmAPyvs31nesMtsQTuYEeDcO5 RHI+EOI2Dt9OiZOwRxpNneTpME4nvJtPi0qnkcdJqvxaYjoICO6c0XRuKLHOMn/r00 +VOKxhIKBpGdNbaotpasz+jYUffQAL1FpsSHGv0CjHQ4BKaYF/M31pNWyuobyNNEE6 td1NbUcBLbGrilPHJqNRRts+3VPhp+GmF/JDA+EhBgf+qpfvAte5RiZTRXajvVjV6b 1ZU3EHqhctuTPEbExTsuBBCMqqkXVOLcbWnXwit7w/Rya5hryY80kC+HHbXnHO1OJa IY5BxA2lvhcuA== Subject: Re: [clue] Its not "legacy", its ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:12:14 -0000 On 10/3/13 12:59 PM, DRAGE, Keith (Keith) wrote: > English doesn’t work that way. The only way to do what you are doing is > to say “CLUE non-enabled” or probably more correctly “CLUE not enabled”. This is why we coin special terms and give them precise definitions. If they look like regular words then its best if the precise definitions are consistent with the informal connotation of the words, but ultimately it is the formal definition that matters. Thanks, Paul > Keith > > ------------------------------------------------------------------------ > > *From:*Jonathan Lennox [mailto:jonathan@vidyo.com] > *Sent:* 03 October 2013 15:56 > *To:* DRAGE, Keith (Keith) > *Cc:* Mary Barnes; CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > You're running into the problem of the lack of scoping parentheses in > natural language. It's not (non-CLUE) enabled, it's non-(CLUE enabled). > > Would "non-CLUE-enabled" (with the extra hyphen) be clearer? > > On Oct 2, 2013, at 10:45 AM, "DRAGE, Keith (Keith)" > > > > wrote: > > > > If you don’t have a telephone, you don’t suddenly have a > “non-telephone”, on which you make your “non-calls”. > > You need to apply the negation to the right word, and it is not CLUE > that is subject to the negation. > > Keith > > ------------------------------------------------------------------------ > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com ] > *Sent:* 02 October 2013 15:17 > *To:* DRAGE, Keith (Keith) > *Cc:* Paul Coverdale; CLUE > *Subject:* Re: [clue] Its not "legacy", its ??? > > "non-CLUE enabled" means the endpoint does not support the CLUE protocol > (at all) or the endpoint is not using the CLUE protocol for whatever > reason (e.g., fallback case) > > I think the "non-CLUE" is more in line with the original implication of > the term "legacy". > > Mary . > > On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) > > > wrote: > > Just to add a pedantic point, I am not sure what a “non-CLUE” is. What > we have is something where CLUE does not exist, not the creation of some > other concept of a “non-CLUE” to complement a “CLUE”. You want to apply > the negation to the “enabled” which is something like “disabled”, > “unenabled” or whatever. > > Keith > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] *On Behalf > Of *Mary Barnes > *Sent:* 02 October 2013 14:57 > *To:* Paul Coverdale > *Cc:* CLUE > > > *Subject:* Re: [clue] Its not "legacy", its ??? > > It is a fine line. I personally have a preference for "non-CLUE > enabled". I really don't think we'll be using that in too many places > in the documents that it's too much typing. If someone thinks that's > the case, perhaps we use "clueless" in the docs until we're ready to > ship them out of the WG and then just do a global change. As I've said > before for XCON, we do use the term "non-XCON enabled" which I think has > the right semantics and really isn't too much of a mouthful to say either. > > Mary. > > On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale > wrote: > > I thought the proposal of "clueless' was just a joke when I first saw it, > but apparently not. > > I think this term will just invite ridicule. It's a bit of a mouthful, but I > would suggest "non-CLUE" equipped". But if you insist on using "clueless", > at least hyphenate it (clue-less). > > ...Paul > > >>-----Original Message----- >>From:clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] On Behalf Of > >>Paul Kyzivat >>Sent: Tuesday,October 01, 2013 5:40 PM >>To:clue@ietf.org >>Subject: Re: [clue] Its not "legacy", its ??? >> > >>On 10/1/13 12:45 PM, Robert Hansen wrote: >>> I am personally very fond of 'CLUEless' :) >> >>One of the reasons I liked the name "clue" for the wg was because it >>gave us an excuse to use "clueless" and "clueful". However they do have >>the feel of "informal" usage - a bit odd for formal use. (But I can get >>over that.) >> >> Thanks, >> Paul >> >>> Rob >>> >>> On 01/10/2013 17:22, Paul Kyzivat wrote: >>>> Mary, >>>> >>>> The minutes are now posted. We did talk about this, briefly. >>>> We decided we didn't want to use the meeting time to discuss what >>>> word to use - that we could do that on the list. >>>> >>>> I agree with you, I also think "legacy" has the wrong connotation for >>>> what we mean, so I would like to find a better term. I have no ideas >>>> that I love, but a couple that I could live with: "non-clue", >>"clueless". >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/1/13 10:26 AM, Mary Barnes wrote: >>>>> I'm in another meeting so unfortunately cannot attend today. But, I >>>>> would really, really like to get away from the term "legacy" - the >>>>> English language definition of "legacy" is not correct. CLUE isn't >>>>> superseding any functionality of current SIP endpoints. It's adding >>>>> additional functionality. I would much rather select something like >>>>> "non-Clue enabled endpoint". We can shorten if folks are concerned >>>>> about the length of a more appropriate alternative term. >>>>> >>>>> As an aside, IMHO, the RTCWEB folks using the term "legacy" is >>>>> slightly more appropriate since it's a different architecture and >>>>> entirely new application - i.e., it isn't based on RFC 3261, but >>>>> CLUE is, so any suggestion that it's replacing any current SIP >>>>> functionality isn't correct. >>>>> >>>>> Regards, >>>>> Mary. >>>>> >>>>> >>>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat >>>>> >> wrote: >>>>> >>>>> You can find Christer's slides for today at: >>>>> >>>>> > >>>>> http://trac.tools.ietf.org/wg/__clue/trac/attachment/wiki/__Design-T >>>>> eam/CLUE_Legacy___1oct13.pptx >>>>> >>>>> >>>>> >>>>> >>>>> /CLUE_Legacy_1oct13.pptx> >>>>> >>>>> >>>>> >>>>> See you shortly. >>>>> >>>>> Paul >>>>> _________________________________________________ >>>>> clue mailing list >>>>>clue@ietf.org > >>>>>https://www.ietf.org/mailman/__listinfo/clue >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>>clue@ietf.org >>>>https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>>clue@ietf.org >>>https://www.ietf.org/mailman/listinfo/clue >>> >> >>_______________________________________________ >>clue mailing list >>clue@ietf.org >>https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Sun Oct 6 13:48:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D9B1F0ED7 for ; Sun, 6 Oct 2013 13:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.112 X-Spam-Level: X-Spam-Status: No, score=-0.112 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUuDZ5RErHhR for ; Sun, 6 Oct 2013 13:48:33 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id AB98C1F0ED1 for ; Sun, 6 Oct 2013 13:48:28 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id ZwGH1m00116LCl05AwoTwc; Sun, 06 Oct 2013 20:48:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id ZwoT1m00Z3ZTu2S3SwoT2j; Sun, 06 Oct 2013 20:48:27 +0000 Message-ID: <5251CC9A.8080202@alum.mit.edu> Date: Sun, 06 Oct 2013 16:48:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE References: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> In-Reply-To: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381092507; bh=+b+y391VdRAvLtytP+a+dec34zoVJrC4I+oKHj9M1Uo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CHoh52u/pO1CxogcAioKGOH052xpuL6Zv3Blc8zL09Ic99rb51gaq5L24LyTBkgnL TgVXmJ/UkHdV8dChDvHofvu0Cy4t2IpPnlV8N0wd5N2QYaas0x7Hgj2nDiRq6cs+GY rc2n3BTgaFwk4x1qRLrQr5GKnKhLwFdaldTwrJlZ21Ic/b3QOzIaW2SR5ZtQb4m1KV eWv/kR8LZQ6KMAVzoAiSxP5IUlrnINTIfpT3i7M+DURkagNNOPvutSIH2PIA6A0rU9 16GxAO3kmvr+A+UjDgIoXlT6yzJL1itA3aXXZoK96W4h1MhZffG0QI97ep32a6Th5F W0C7TrZ5uel4A== Subject: Re: [clue] IETF 88 Preliminary Agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 20:48:37 -0000 CLUE people who will be attending IETF88: Heads up. The preliminary schedule is out for the meeting, and our 2nd CLUE session is scheduled for Friday afternoon. While there may be schedule changes before this is finalized, don't count on this getting better. So when making your travel plans, please don't plan to depart Friday afternoon. Thanks, Paul -------- Original Message -------- Subject: IETF 88 Preliminary Agenda Date: Fri, 04 Oct 2013 15:53:46 -0700 From: IETF Agenda Reply-To: ietf@ietf.org, agenda@ietf.org To: IETF Announcement List CC: ietf@ietf.org The IETF 88 Preliminary Agenda has been posted. The final agenda will be published on Friday, October 11th. https://datatracker.ietf.org/meeting/88/agenda.html https://datatracker.ietf.org/meeting/88/agenda.txt We are still having some difficulty integrating the new agenda tool into the datatracker and as a result some portions of the meeting agenda -- beverage and snack breaks, plenaries -- are not yet showing up on the html version. This will hopefully be resolved very soon. More information regarding IETF 88 in Vancouver, BC, Canada is located here: https://www.ietf.org/meeting/88/index.html IETF Secretariat From coverdale@sympatico.ca Sun Oct 6 14:08:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C954621F9D09 for ; Sun, 6 Oct 2013 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxX7UIi94a+k for ; Sun, 6 Oct 2013 14:08:15 -0700 (PDT) Received: from blu0-omc1-s14.blu0.hotmail.com (blu0-omc1-s14.blu0.hotmail.com [65.55.116.25]) by ietfa.amsl.com (Postfix) with ESMTP id B163C21F9EE1 for ; Sun, 6 Oct 2013 14:08:15 -0700 (PDT) Received: from BLU0-SMTP48 ([65.55.116.7]) by blu0-omc1-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 Oct 2013 14:08:10 -0700 X-TMN: [OCDogWwDuOM3Wscefv4glfYgKO69+5g/] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.12.62.210]) by BLU0-SMTP48.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 6 Oct 2013 14:08:07 -0700 From: Paul Coverdale To: "'Paul Kyzivat'" , "'CLUE'" References: <20131004225346.32223.38527.idtracker@ietfa.amsl.com> <5251CC9A.8080202@alum.mit.edu> In-Reply-To: <5251CC9A.8080202@alum.mit.edu> Date: Sun, 6 Oct 2013 17:08:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7C1XLKrd7TtyQrR+qNX90bsY5VSAAAjPHQ Content-Language: en-us X-OriginalArrivalTime: 06 Oct 2013 21:08:08.0208 (UTC) FILETIME=[281DA900:01CEC2D8] Subject: Re: [clue] IETF 88 Preliminary Agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 21:08:21 -0000 You had me worried for a while, since I've already booked my flights, but it seems that the "afternoon" session ends at 13:30, not too late for a quick dash to YVR... ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Sunday, October 06, 2013 4:48 PM >To: CLUE >Subject: Re: [clue] IETF 88 Preliminary Agenda > >CLUE people who will be attending IETF88: > >Heads up. The preliminary schedule is out for the meeting, and our 2nd >CLUE session is scheduled for Friday afternoon. While there may be >schedule changes before this is finalized, don't count on this getting >better. > >So when making your travel plans, please don't plan to depart Friday >afternoon. > > Thanks, > Paul > > >-------- Original Message -------- >Subject: IETF 88 Preliminary Agenda >Date: Fri, 04 Oct 2013 15:53:46 -0700 >From: IETF Agenda >Reply-To: ietf@ietf.org, agenda@ietf.org >To: IETF Announcement List >CC: ietf@ietf.org > >The IETF 88 Preliminary Agenda has been posted. The final agenda will be >published on Friday, October 11th. > >https://datatracker.ietf.org/meeting/88/agenda.html >https://datatracker.ietf.org/meeting/88/agenda.txt > >We are still having some difficulty integrating the new agenda tool into >the datatracker and as a result some portions of the meeting agenda -- >beverage and snack breaks, plenaries -- are not yet showing up on the >html version. This will hopefully be resolved very soon. > >More information regarding IETF 88 in Vancouver, BC, Canada is located >here: https://www.ietf.org/meeting/88/index.html > >IETF Secretariat > > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Oct 7 20:40:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765E321E8128 for ; Mon, 7 Oct 2013 20:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp7qKLpmO48L for ; Mon, 7 Oct 2013 20:40:32 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 5555621E8122 for ; Mon, 7 Oct 2013 20:40:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAOV9U1J20bHs/2dsb2JhbAANTIM/wXOBNoMZAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiA6oEJMcBI9YFoQNA605 Received: from ppp118-209-177-236.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.177.236]) by ipmail06.adl6.internode.on.net with ESMTP; 08 Oct 2013 14:10:25 +1030 Message-ID: <52537EA6.2090700@nteczone.com> Date: Tue, 08 Oct 2013 14:40:22 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <524B9464.7060708@nteczone.com> In-Reply-To: <524B9464.7060708@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] MCC in framework? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 03:40:32 -0000 Does anyone have any further comments / questions on the MCC? If people have concerns it would be good to know them so that they can be addressed before the upcoming IETF meeting. Regards, Christian On 2/10/2013 1:35 PM, Christian Groves wrote: > Hello all, > > We've had some discussion on the mailing list regarding the MCC > concept? The response seems to be cautiously positive. Is this > something that people are happy to move forward with in the framework? > > I'd be happy to work with Mark for some text for the framework. At > least if there's text then we can iron out any issues. > > There is still the issue of full updates vs deltas but I don't think > that's a specific problem of the MCC concept. > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From rohanse2@cisco.com Tue Oct 8 01:34:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6BB21E817A for ; Tue, 8 Oct 2013 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKV5W+0-4GxG for ; Tue, 8 Oct 2013 01:34:35 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A4F9921E8179 for ; Tue, 8 Oct 2013 01:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35071; q=dns/txt; s=iport; t=1381221272; x=1382430872; h=message-id:date:from:mime-version:to:subject; bh=GHOYQMMZ4dA8CN7gDdRmYS3pRe9ZO4xDl4KUrWMSNR0=; b=g4DhfiZlAesYi80Y3Z8MxrTXuYF9OQuIAuOfi8w8aYGsbJFyE+v8N8JT Fdg+e32P/VdKrk3pWXdk2MSYKTq9W2vobY6ok05uvo81RoWryYbBAd/+A hGgV6FGK1JGkhU1cvMtIICkHlxgvfUPwtFyXZMFF+BDIOm4/eJtm/EUS8 4=; X-Files: clue_encodings_negotiation.txt : 14322 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAJTCU1KQ/khN/2dsb2JhbABZgweKD7k7FnSCRl49FhEHAwIBAgFYCAEBiAKZNKE5jXgLhWgDkCiBMIYphjaEFoc0gyU7gSwBBAICFw X-IronPort-AV: E=Sophos;i="4.90,1056,1371081600"; d="txt'?scan'208";a="18607066" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 08 Oct 2013 08:34:31 +0000 Received: from [10.47.196.64] ([10.47.196.64]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r988YQYr011878 for ; Tue, 8 Oct 2013 08:34:28 GMT Message-ID: <5253C3C5.6080207@cisco.com> Date: Tue, 08 Oct 2013 09:35:17 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org Content-Type: multipart/mixed; boundary="------------090901000800030905080508" Subject: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 08:34:40 -0000 This is a multi-part message in MIME format. --------------090901000800030905080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At the design meeting last week I volunteered to take a stab at evaluating alternate approaches to conveying all encoding information in SDP. The text got a bit long for an email, so I've also attached it as a text document. I'll also put together some slides on the topic for this call this afternoon. One of the fundamental issues we have in clue is how to negotiate the details of the encodings defined in draft-ietf-clue-framework. Unless other entities such as captures, which are unique to CLUE, encodings share many properties with limits that are currently expressible in SDP, but have additional requirements and limits that are less good fits for SDP. One of the The current assumption we have been working from, as detailed in draft-kyzivat-clue-signaling, is that the encodings (defined in draft-ietf-clue-framework), will be expressed in SDP and not in the CLUE signalling. However, this has only ever been a working assumption rather than something we've reached consensus on, and this is a fundamental design decision that impacts not just the message syntax but also the call flows and state machines inherent in the signalling. As such, I volunteered to examine the alternative approach, to hopefully allow us to resolve this issue so we can move forward. To do this I am going to examine two alternate options (for deails of the SDP approach see draft-kyzivat-clue-signaling). One is to, where possible, negotiate the limits and use of multiple video and audio subsessions as part of the CLUE Advertisment/Configure exchange, with the negotiated SDP m-lines treated as an 'envelope' subdivided by CLUE; this approach was the one that had more initial exploration by the CLUE WG before we moved towards the SDP approach. The other approach is a half-way house that has not yet been explored in any detail; this is to negotiate each channel in SDP, but to express the encoding constraints within the CLUE signalling. *** Encodings in CLUE *** In this approach the encodings available, and the constraints associated with them, are expressed in the CLUE Advertisment. The far end then selects which encodings they wish to receive, and the limits on those encodings as part of the CLUE Configure message. In the simplest (and, most likely, commonest case) this would allow a single sendrecv m-line per media type to be used for all sent and received CLUE-controlled streams. The various streams must then be demultiplexed; this can be done via explicit SSRC for static streams or via an additional header such as appId. SSRC is used in examples; replacing these with appId indicators should be roughly equivalent for streams with dynamic SSRCs. As such the initial SDP, and then Advertiment, might look something like: EXAMPLE SDP OFFER (from A) m=video ... ... a=ssrc:1234 a=ssrc:2345 a=ssrc:3456 a=sendrecv EXAMPLE ADVERTISMENT (from A) Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, ssrc=1234 Encoding 2: H264, 1080p30, ssrc=2345 Encoding 3: H264, 1080p30, ssrc=3456 The SSRC/appId attributes are ignorable and hence sendable in the initial SSRC, though implementations may prefer to leave them out initially and then readvertise once CLUE is established. I've also included SSRCs alongside the encodings. In this case all encodings are on the same m-line, but there are scenarios where this multiplexing may not be appropriate or even possible, such as the disaggregated case when different streams must be sent to different IP addresses. In such circumstances there is a need to be able to distinguish which encodings can be sent on which m-line. An alternative would be to have the SSRCs only in SDP, and use something else to tie that to the encodings (such as a label attribute). Having the encodings split across multiple m-lines will present additional challenges, which will be detailed later. For now, consider the rest of the simple case. The far end will complete the SDP negotiation, and send a Configure message choosing what to receive, something like this: EXAMPLE SDP ANSWER (from B) m=video ... ... H264@720p30 a=sendrecv EXAMPLE CONFIGURATION (from B) Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3 At this point the sender can begin sending three media streams, which the receiver can demultiplex by SSRC. However, one major issue remains even for the multiplexed case: how to express receiver encode limitations. These are currently expressed in SDP, and are defined to apply to a single media stream. However, in the case above three streams are being sent to that port, and we have to decide what those limits mean. One answer would be that it provides the *overall* limit, but this quickly runs into problems. One issue is that not all parameters can be sensibly subdivided: for H264 max-br and max-mbps could be divided into three relatively easily, but max-fs makes less sense. And even avoiding this, it would allow the far end to validly send a single stream that matched the combined limit, which the receiver might not be able to cope with; existing 3-screen systems often have three seperate decoders that cannot pool their decode resource (eg, they might be able to decode three 720p streams, but not one 1080p stream). As such a better answer is that the SDP receive limits express the limit for *any* individual stream; in the example above each of the three streams could be sent at up to 720p30. However, this still poses an issue: what happens if the receiver wants to receive different capture encodings with different constraints. In the example above most receivers will probably want all three streams at similar resolutions, but in the scenario where a device wants to receive one primary capture encoding to view full-screne and six capture-encodings to use as small picture-in-picture insets then the receiver needs to be able to express these different constraints. One option is for the SDP codec limit to provide a set of maxima for any given stream, but then be able to express *additional* limits for each capture encoding as part of the Configure message; a highly simplified version might look like this: EXAMPLE CONFIGURATION (from B) Capture 1, Encoding 1, 720p30 Capture 2, Encoding 2, 360p30 Capture 3, Encoding 3, 360p30 These would provide additional constraints on what could be sent for each stream; they could only lower (not raise) the constraints expressed in SDP. On the plus side, the 'encodings in CLUE' approach will mean we need to create syntax to express codec-specific encoder limitations for the Advertise messages, and much of that syntax could use here. On the minus side, this means replicating functionality that is already part of SDP. If we don't want to go down the route of re-expressing codec limits in CLUE there is another option, which is that receivers that want to express different receive limits for different capture encodings they wish to receive will need to create new m-lines in the SDP so they can differentiate between the capture encodings they want to receive. The plus side of this approach is that this is a requirement of the 'Encodings in CLUE' approach anyway, as it's needed for the case where the initial answerer is a disaggregated system that doesn't want to multiplex their streams; these scenarios will also need to reoffer with new m-lines and split up the streams. The downside of this approach is that coming up with a general way to mix and match multiple m-line each of which may multiplex different streams, and the ability to change the the number of m-lines in use and which encodings are multiplexed onto each is painful, to the point where I don't have a particularly good handle on it. I've included some initial speculation in an appendix at the end of the page to avoid eating up too much space here. Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': * 'Encodings in SDP' approach can't express all H.264 send limitations using existing SDP syntax * In the straightforward multiplexed case fewer (or no) additional O/As and m-lines Disadvantages: * Need to reinvent syntax to express H264 (and any other codec) limitations * Problems with moving from multiplexed to non-multiplexed (and similar) * Media-specific information in CLUE messaging, potentially limiting interoperability with other ongoing multistream work *** Encoding Constraints in CLUE *** This scenario presents a half-way house between the 'Encodings in CLUE' approach expressed above and the 'Encodings in SDP' approach expressed in draft-kyzivat-clue-signaling. In this case there is a seperate m-line per stream, just as with the 'Encodings in SDP' approach. However, in this approach the encoding constraints are expressed in the CLUE Advertisment. Let us explore the three-screen example from before with this new approach. There will be an initial SDP O/A to establish the CLUE channel and verify that both sides support CLUE. There is then a new SDP offer with an m-line per stream available, and a matching advertisment: EXAMPLE SDP OFFER (from A) m=video ... ... H264@720p30 a=label:A a=sendrecv m=video ... ... H264@720p30 a=label:B a=sendrecv m=video ... ... H264@720p30 a=label:C a=sendrecv EXAMPLE ADVERTISMENT (from A) Capture Scene 1: Capture 1: Left (Encoding Group 1) Capture 2: Center (Encoding Group 1) Capture 3: Right (Encoding Group 1) Capture 4: Switched Capture Scene Entry 1: 1,2,3 Capture Scene Entry 2: 4 Simultaneous Sets: 1,2,3,4 Encoding Group 1: Encoding 1: H264, 1080p30, label=A Encoding 2: H264, 1080p30, label=B Encoding 3: H264, 1080p30, label=C I've used label above to tie the encodings to the m-lines, but this could alternately be SSRC (if SSRC was being used), appId (if appId were being used) or anything else. This closely matches the examples in draft-kyzivat-clue-signaling. However, the sender can use 'sendrecv' rather than 'sendonly' for the new m-lines rather than 'sendonly', as the encoder limits are expressed instead in CLUE. This also has the advantage that the CLUE syntax for these limits allows the precise H264 send limits to be expressed (while SDP limits which parameters can be used in H.264 sendonly). If the far end wants to receive the three static captures then it sends an answer SDP which can accept those, along with a Configure message specifying which captures it wants to receive: EXAMPLE SDP ANSWER (from B) m=video ... ... H264@720p30 a=sendrecv m=video ... ... H264@720p30 a=sendrecv m=video ... ... H264@720p30 a=sendrecv EXAMPLE CONFIGURATION (from B) Capture 1, Encoding 1 Capture 2, Encoding 2 Capture 3, Encoding 3 The receiver no longer needs to express the receive limits in CLUE; with an m-line per received stream the standard SDP parameters already allow full expression of the limitations. Now it just needs to state what encoding it wants to use for each capture it receives. Also, in the SDP the new m-lines are marked as 'sendrecv'; if we consider the other direction (B sendings to A) then if B has three streams or fewer then it will not have to make a new SDP offer. For instance, if B supported up to two encodings its response could instead have been: EXAMPLE SDP ANSWER (from B) m=video ... ... H264@720p30 a=sendrecv m=video ... ... H264@720p30 a=sendrecv m=video ... ... H264@720p30 a=recvonly And could immediately send an Advertisment with its capture and encoding information. A new offer would be needed if B had more encodings than A, or if A wanted to change its receive capabilities based on the capture encodings it wanted from A. This approach is very like the 'Encodings in SDP' approach, with the following advantages and disadvantages: Advantages relative to 'Encodings in SDP': * 'Encodings in SDP' approach can't express all H.264 send limitations using existing SDP syntax * Many m-lines can be sendrecv, in many cases will need fewer O/As Disadvantages: * Still need to reinvent syntax to express H264 (and any other codec) encoding limitations *** Summary *** Appealing as the 'Encodings in CLUE' case is when all streams of a given media type can be multiplexed onto a single m-line, treating SDP as an 'envelope' CLUe can subdivide, I don't believe this approach is actually feasible. Also having to support the multiple m-line case and be able to sensibly change the number of m-lines is painful, while the need to replicate receive codec limits in CLUE that are already expressed very capably in SDP is unlikely to be popular. I believe the 'Encoding *constraints* in CLUE' approach is considerably more plausible, though the variation from the 'Encodings in SDP' approach is fairly small. Principly it comes down to whether the work required to develop syntax to express the send limits for the various codecs in CLUE is worth the added accuracy of what can be expressed in CLUE over what is currently available in SDP, along with the advantage of less need to add new m-lines (and the associated O/As involved). *** Appendix *** Let us first consider the case of wanting to split an offered set of streams. The sender (A) can send up to five capture encodings, and so send an SDP offer along the lines of: m=video ... ... a=ssrc:1234 a=ssrc:2345 a=ssrc:3456 a=ssrc:4567 a=ssrc:5678 a=sendrecv The receiver (B) wants to receive one of those streams on one m-line, three more on a second m-line and the fifth not at all. The rules of O/A mean that B must send an initial answer with the single m-line, which we won't illustrate here, and then send a new offer. Some method must be provided to show what streams are to be received where; in this case I'm using the max-ssrc draft: m=video ... ... a=max-recv-ssrc:{*:1} a=sendrecv m=video ... ... a=max-recv-ssrc:{*:3} a=sendrecv m=video ... 0 A will then need to reorder their allocation of SSRCs to m-lines to sensibly fit this. And if later in the call B decides that it now wants to multiplex all of the streams this will need to be done in reverse, with B sending a new offer with only one activevideo m-line and suitable max-recv-ssrc value and hope that A will correctly interpret this. This reallocation of streams between m-lines is the part I think will be difficult to define normatively. Rob --------------090901000800030905080508 Content-Type: text/plain; charset=windows-1252; name="clue_encodings_negotiation.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="clue_encodings_negotiation.txt" T25lIG9mIHRoZSBmdW5kYW1lbnRhbCBpc3N1ZXMgd2UgaGF2ZSBpbiBjbHVlIGlzIGhvdyB0 byBuZWdvdGlhdGUgdGhlIGRldGFpbHMgb2YgdGhlIGVuY29kaW5ncyBkZWZpbmVkIGluIGRy YWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmsuIFVubGVzcyBvdGhlciBlbnRpdGllcyBzdWNoIGFz IGNhcHR1cmVzLCB3aGljaCBhcmUgdW5pcXVlIHRvIENMVUUsIGVuY29kaW5ncyBzaGFyZSBt YW55IHByb3BlcnRpZXMgd2l0aCBsaW1pdHMgdGhhdCBhcmUgY3VycmVudGx5IGV4cHJlc3Np YmxlIGluIFNEUCwgYnV0IGhhdmUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgYW5kIGxpbWl0 cyB0aGF0IGFyZSBsZXNzIGdvb2QgZml0cyBmb3IgU0RQLiBPbmUgb2YgdGhlIA0KDQpUaGUg Y3VycmVudCBhc3N1bXB0aW9uIHdlIGhhdmUgYmVlbiB3b3JraW5nIGZyb20sIGFzIGRldGFp bGVkIGluIGRyYWZ0LWt5eml2YXQtY2x1ZS1zaWduYWxpbmcsIGlzIHRoYXQgdGhlIGVuY29k aW5ncyAoZGVmaW5lZCBpbiBkcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrKSwgd2lsbCBiZSBl eHByZXNzZWQgaW4gU0RQIGFuZCBub3QgaW4gdGhlIENMVUUgc2lnbmFsbGluZy4gSG93ZXZl ciwgdGhpcyBoYXMgb25seSBldmVyIGJlZW4gYSB3b3JraW5nIGFzc3VtcHRpb24gcmF0aGVy IHRoYW4gc29tZXRoaW5nIHdlJ3ZlIHJlYWNoZWQgY29uc2Vuc3VzIG9uLCBhbmQgdGhpcyBp cyBhIGZ1bmRhbWVudGFsIGRlc2lnbiBkZWNpc2lvbiB0aGF0IGltcGFjdHMgbm90IGp1c3Qg dGhlIG1lc3NhZ2Ugc3ludGF4IGJ1dCBhbHNvIHRoZSBjYWxsIGZsb3dzIGFuZCBzdGF0ZSBt YWNoaW5lcyBpbmhlcmVudCBpbiB0aGUgc2lnbmFsbGluZy4gQXMgc3VjaCwgSSB2b2x1bnRl ZXJlZCB0byBleGFtaW5lIHRoZSBhbHRlcm5hdGl2ZSBhcHByb2FjaCwgdG8gaG9wZWZ1bGx5 IGFsbG93IHVzIHRvIHJlc29sdmUgdGhpcyBpc3N1ZSBzbyB3ZSBjYW4gbW92ZSBmb3J3YXJk Lg0KDQpUbyBkbyB0aGlzIEkgYW0gZ29pbmcgdG8gZXhhbWluZSB0d28gYWx0ZXJuYXRlIG9w dGlvbnMgKGZvciBkZWFpbHMgb2YgdGhlIFNEUCBhcHByb2FjaCBzZWUgZHJhZnQta3l6aXZh dC1jbHVlLXNpZ25hbGluZykuIE9uZSBpcyB0bywgd2hlcmUgcG9zc2libGUsIG5lZ290aWF0 ZSB0aGUgbGltaXRzIGFuZCB1c2Ugb2YgbXVsdGlwbGUgdmlkZW8gYW5kIGF1ZGlvIHN1YnNl c3Npb25zIGFzIHBhcnQgb2YgdGhlIENMVUUgQWR2ZXJ0aXNtZW50L0NvbmZpZ3VyZSBleGNo YW5nZSwgd2l0aCB0aGUgbmVnb3RpYXRlZCBTRFAgbS1saW5lcyB0cmVhdGVkIGFzIGFuICdl bnZlbG9wZScgc3ViZGl2aWRlZCBieSBDTFVFOyB0aGlzIGFwcHJvYWNoIHdhcyB0aGUgb25l IHRoYXQgaGFkIG1vcmUgaW5pdGlhbCBleHBsb3JhdGlvbiBieSB0aGUgQ0xVRSBXRyBiZWZv cmUgd2UgbW92ZWQgdG93YXJkcyB0aGUgU0RQIGFwcHJvYWNoLiBUaGUgb3RoZXIgYXBwcm9h Y2ggaXMgYSBoYWxmLXdheSBob3VzZSB0aGF0IGhhcyBub3QgeWV0IGJlZW4gZXhwbG9yZWQg aW4gYW55IGRldGFpbDsgdGhpcyBpcyB0byBuZWdvdGlhdGUgZWFjaCBjaGFubmVsIGluIFNE UCwgYnV0IHRvIGV4cHJlc3MgdGhlIGVuY29kaW5nIGNvbnN0cmFpbnRzIHdpdGhpbiB0aGUg Q0xVRSBzaWduYWxsaW5nLg0KDQoqKiogRW5jb2RpbmdzIGluIENMVUUgKioqDQoNCkluIHRo aXMgYXBwcm9hY2ggdGhlIGVuY29kaW5ncyBhdmFpbGFibGUsIGFuZCB0aGUgY29uc3RyYWlu dHMgYXNzb2NpYXRlZCB3aXRoIHRoZW0sIGFyZSBleHByZXNzZWQgaW4gdGhlIENMVUUgQWR2 ZXJ0aXNtZW50LiBUaGUgZmFyIGVuZCB0aGVuIHNlbGVjdHMgd2hpY2ggZW5jb2RpbmdzIHRo ZXkgd2lzaCB0byByZWNlaXZlLCBhbmQgdGhlIGxpbWl0cyBvbiB0aG9zZSBlbmNvZGluZ3Mg YXMgcGFydCBvZiB0aGUgQ0xVRSBDb25maWd1cmUgbWVzc2FnZS4NCg0KSW4gdGhlIHNpbXBs ZXN0IChhbmQsIG1vc3QgbGlrZWx5LCBjb21tb25lc3QgY2FzZSkgdGhpcyB3b3VsZCBhbGxv dyBhIHNpbmdsZSBzZW5kcmVjdiBtLWxpbmUgcGVyIG1lZGlhIHR5cGUgdG8gYmUgdXNlZCBm b3IgYWxsIHNlbnQgYW5kIHJlY2VpdmVkIENMVUUtY29udHJvbGxlZCBzdHJlYW1zLiBUaGUg dmFyaW91cyBzdHJlYW1zIG11c3QgdGhlbiBiZSBkZW11bHRpcGxleGVkOyB0aGlzIGNhbiBi ZSBkb25lIHZpYSBleHBsaWNpdCBTU1JDIGZvciBzdGF0aWMgc3RyZWFtcyBvciB2aWEgYW4g YWRkaXRpb25hbCBoZWFkZXIgc3VjaCBhcyBhcHBJZC4gU1NSQyBpcyB1c2VkIGluIGV4YW1w bGVzOyByZXBsYWNpbmcgdGhlc2Ugd2l0aCBhcHBJZCBpbmRpY2F0b3JzIHNob3VsZCBiZSBy b3VnaGx5IGVxdWl2YWxlbnQgZm9yIHN0cmVhbXMgd2l0aCBkeW5hbWljIFNTUkNzLiBBcyBz dWNoIHRoZSBpbml0aWFsIFNEUCwgYW5kIHRoZW4gQWR2ZXJ0aW1lbnQsIG1pZ2h0IGxvb2sg c29tZXRoaW5nIGxpa2U6DQoNCkVYQU1QTEUgU0RQIE9GRkVSIChmcm9tIEEpDQptPXZpZGVv IC4uLg0KLi4uDQphPXNzcmM6MTIzNA0KYT1zc3JjOjIzNDUNCmE9c3NyYzozNDU2DQphPXNl bmRyZWN2DQoNCkVYQU1QTEUgQURWRVJUSVNNRU5UIChmcm9tIEEpDQogQ2FwdHVyZSBTY2Vu ZSAxOg0KICBDYXB0dXJlIDE6IExlZnQgKEVuY29kaW5nIEdyb3VwIDEpDQogIENhcHR1cmUg MjogQ2VudGVyIChFbmNvZGluZyBHcm91cCAxKQ0KICBDYXB0dXJlIDM6IFJpZ2h0IChFbmNv ZGluZyBHcm91cCAxKQ0KICBDYXB0dXJlIDQ6IFN3aXRjaGVkDQogIENhcHR1cmUgU2NlbmUg RW50cnkgMTogMSwyLDMNCiAgQ2FwdHVyZSBTY2VuZSBFbnRyeSAyOiA0DQogIFNpbXVsdGFu ZW91cyBTZXRzOiAxLDIsMyw0DQogRW5jb2RpbmcgR3JvdXAgMToNCiAgRW5jb2RpbmcgMTog SDI2NCwgMTA4MHAzMCwgc3NyYz0xMjM0DQogIEVuY29kaW5nIDI6IEgyNjQsIDEwODBwMzAs IHNzcmM9MjM0NQ0KICBFbmNvZGluZyAzOiBIMjY0LCAxMDgwcDMwLCBzc3JjPTM0NTYNCg0K VGhlIFNTUkMvYXBwSWQgYXR0cmlidXRlcyBhcmUgaWdub3JhYmxlIGFuZCBoZW5jZSBzZW5k YWJsZSBpbiB0aGUgaW5pdGlhbCBTU1JDLCB0aG91Z2ggaW1wbGVtZW50YXRpb25zIG1heSBw cmVmZXIgdG8gbGVhdmUgdGhlbSBvdXQgaW5pdGlhbGx5IGFuZCB0aGVuIHJlYWR2ZXJ0aXNl IG9uY2UgQ0xVRSBpcyBlc3RhYmxpc2hlZC4gDQoNCkkndmUgYWxzbyBpbmNsdWRlZCBTU1JD cyBhbG9uZ3NpZGUgdGhlIGVuY29kaW5ncy4gSW4gdGhpcyBjYXNlIGFsbCBlbmNvZGluZ3Mg YXJlIG9uIHRoZSBzYW1lIG0tbGluZSwgYnV0IHRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUg dGhpcyBtdWx0aXBsZXhpbmcgbWF5IG5vdCBiZSBhcHByb3ByaWF0ZSBvciBldmVuIHBvc3Np YmxlLCBzdWNoIGFzIHRoZSBkaXNhZ2dyZWdhdGVkIGNhc2Ugd2hlbiBkaWZmZXJlbnQgc3Ry ZWFtcyBtdXN0IGJlIHNlbnQgdG8gZGlmZmVyZW50IElQIGFkZHJlc3Nlcy4gSW4gc3VjaCBj aXJjdW1zdGFuY2VzIHRoZXJlIGlzIGEgbmVlZCB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNo IHdoaWNoIGVuY29kaW5ncyBjYW4gYmUgc2VudCBvbiB3aGljaCBtLWxpbmUuIEFuIGFsdGVy bmF0aXZlIHdvdWxkIGJlIHRvIGhhdmUgdGhlIFNTUkNzIG9ubHkgaW4gU0RQLCBhbmQgdXNl IHNvbWV0aGluZyBlbHNlIHRvIHRpZSB0aGF0IHRvIHRoZSBlbmNvZGluZ3MgKHN1Y2ggYXMg YSBsYWJlbCBhdHRyaWJ1dGUpLiANCg0KSGF2aW5nIHRoZSBlbmNvZGluZ3Mgc3BsaXQgYWNy b3NzIG11bHRpcGxlIG0tbGluZXMgd2lsbCBwcmVzZW50IGFkZGl0aW9uYWwgY2hhbGxlbmdl cywgd2hpY2ggd2lsbCBiZSBkZXRhaWxlZCBsYXRlci4gRm9yIG5vdywgY29uc2lkZXIgdGhl IHJlc3Qgb2YgdGhlIHNpbXBsZSBjYXNlLiBUaGUgZmFyIGVuZCB3aWxsIGNvbXBsZXRlIHRo ZSBTRFAgbmVnb3RpYXRpb24sIGFuZCBzZW5kIGEgQ29uZmlndXJlIG1lc3NhZ2UgY2hvb3Np bmcgd2hhdCB0byByZWNlaXZlLCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpFWEFNUExFIFNE UCBBTlNXRVIgKGZyb20gQikNCm09dmlkZW8gLi4uDQouLi4gSDI2NEA3MjBwMzANCmE9c2Vu ZHJlY3YNCg0KRVhBTVBMRSBDT05GSUdVUkFUSU9OIChmcm9tIEIpDQogQ2FwdHVyZSAxLCBF bmNvZGluZyAxDQogQ2FwdHVyZSAyLCBFbmNvZGluZyAyDQogQ2FwdHVyZSAzLCBFbmNvZGlu ZyAzDQoNCkF0IHRoaXMgcG9pbnQgdGhlIHNlbmRlciBjYW4gYmVnaW4gc2VuZGluZyB0aHJl ZSBtZWRpYSBzdHJlYW1zLCB3aGljaCB0aGUgcmVjZWl2ZXIgY2FuIGRlbXVsdGlwbGV4IGJ5 IFNTUkMuDQoNCkhvd2V2ZXIsIG9uZSBtYWpvciBpc3N1ZSByZW1haW5zIGV2ZW4gZm9yIHRo ZSBtdWx0aXBsZXhlZCBjYXNlOiBob3cgdG8gZXhwcmVzcyByZWNlaXZlciBlbmNvZGUgbGlt aXRhdGlvbnMuIFRoZXNlIGFyZSBjdXJyZW50bHkgZXhwcmVzc2VkIGluIFNEUCwgYW5kIGFy ZSBkZWZpbmVkIHRvIGFwcGx5IHRvIGEgc2luZ2xlIG1lZGlhIHN0cmVhbS4gSG93ZXZlciwg aW4gdGhlIGNhc2UgYWJvdmUgdGhyZWUgc3RyZWFtcyBhcmUgYmVpbmcgc2VudCB0byB0aGF0 IHBvcnQsIGFuZCB3ZSBoYXZlIHRvIGRlY2lkZSB3aGF0IHRob3NlIGxpbWl0cyBtZWFuLg0K DQpPbmUgYW5zd2VyIHdvdWxkIGJlIHRoYXQgaXQgcHJvdmlkZXMgdGhlICpvdmVyYWxsKiBs aW1pdCwgYnV0IHRoaXMgcXVpY2tseSBydW5zIGludG8gcHJvYmxlbXMuIE9uZSBpc3N1ZSBp cyB0aGF0IG5vdCBhbGwgcGFyYW1ldGVycyBjYW4gYmUgc2Vuc2libHkgc3ViZGl2aWRlZDog Zm9yIEgyNjQgbWF4LWJyIGFuZCBtYXgtbWJwcyBjb3VsZCBiZSBkaXZpZGVkIGludG8gdGhy ZWUgcmVsYXRpdmVseSBlYXNpbHksIGJ1dCBtYXgtZnMgbWFrZXMgbGVzcyBzZW5zZS4gQW5k IGV2ZW4gYXZvaWRpbmcgdGhpcywgaXQgd291bGQgYWxsb3cgdGhlIGZhciBlbmQgdG8gdmFs aWRseSBzZW5kIGEgc2luZ2xlIHN0cmVhbSB0aGF0IG1hdGNoZWQgdGhlIGNvbWJpbmVkIGxp bWl0LCB3aGljaCB0aGUgcmVjZWl2ZXIgbWlnaHQgbm90IGJlIGFibGUgdG8gY29wZSB3aXRo OyBleGlzdGluZyAzLXNjcmVlbiBzeXN0ZW1zIG9mdGVuIGhhdmUgdGhyZWUgc2VwZXJhdGUg ZGVjb2RlcnMgdGhhdCBjYW5ub3QgcG9vbCB0aGVpciBkZWNvZGUgcmVzb3VyY2UgKGVnLCB0 aGV5IG1pZ2h0IGJlIGFibGUgdG8gZGVjb2RlIHRocmVlIDcyMHAgc3RyZWFtcywgYnV0IG5v dCBvbmUgMTA4MHAgc3RyZWFtKS4NCg0KQXMgc3VjaCBhIGJldHRlciBhbnN3ZXIgaXMgdGhh dCB0aGUgU0RQIHJlY2VpdmUgbGltaXRzIGV4cHJlc3MgdGhlIGxpbWl0IGZvciAqYW55KiBp bmRpdmlkdWFsIHN0cmVhbTsgaW4gdGhlIGV4YW1wbGUgYWJvdmUgZWFjaCBvZiB0aGUgdGhy ZWUgc3RyZWFtcyBjb3VsZCBiZSBzZW50IGF0IHVwIHRvIDcyMHAzMC4gSG93ZXZlciwgdGhp cyBzdGlsbCBwb3NlcyBhbiBpc3N1ZTogd2hhdCBoYXBwZW5zIGlmIHRoZSByZWNlaXZlciB3 YW50cyB0byByZWNlaXZlIGRpZmZlcmVudCBjYXB0dXJlIGVuY29kaW5ncyB3aXRoIGRpZmZl cmVudCBjb25zdHJhaW50cy4gSW4gdGhlIGV4YW1wbGUgYWJvdmUgbW9zdCByZWNlaXZlcnMg d2lsbCBwcm9iYWJseSB3YW50IGFsbCB0aHJlZSBzdHJlYW1zIGF0IHNpbWlsYXIgcmVzb2x1 dGlvbnMsIGJ1dCBpbiB0aGUgc2NlbmFyaW8gd2hlcmUgYSBkZXZpY2Ugd2FudHMgdG8gcmVj ZWl2ZSBvbmUgcHJpbWFyeSBjYXB0dXJlIGVuY29kaW5nIHRvIHZpZXcgZnVsbC1zY3JlbmUg YW5kIHNpeCBjYXB0dXJlLWVuY29kaW5ncyB0byB1c2UgYXMgc21hbGwgcGljdHVyZS1pbi1w aWN0dXJlIGluc2V0cyB0aGVuIHRoZSByZWNlaXZlciBuZWVkcyB0byBiZSBhYmxlIHRvIGV4 cHJlc3MgdGhlc2UgZGlmZmVyZW50IGNvbnN0cmFpbnRzLg0KDQpPbmUgb3B0aW9uIGlzIGZv ciB0aGUgU0RQIGNvZGVjIGxpbWl0IHRvIHByb3ZpZGUgYSBzZXQgb2YgbWF4aW1hIGZvciBh bnkgZ2l2ZW4gc3RyZWFtLCBidXQgdGhlbiBiZSBhYmxlIHRvIGV4cHJlc3MgKmFkZGl0aW9u YWwqIGxpbWl0cyBmb3IgZWFjaCBjYXB0dXJlIGVuY29kaW5nIGFzIHBhcnQgb2YgdGhlIENv bmZpZ3VyZSBtZXNzYWdlOyBhIGhpZ2hseSBzaW1wbGlmaWVkIHZlcnNpb24gbWlnaHQgbG9v ayBsaWtlIHRoaXM6DQoNCkVYQU1QTEUgQ09ORklHVVJBVElPTiAoZnJvbSBCKQ0KIENhcHR1 cmUgMSwgRW5jb2RpbmcgMSwgNzIwcDMwDQogQ2FwdHVyZSAyLCBFbmNvZGluZyAyLCAzNjBw MzANCiBDYXB0dXJlIDMsIEVuY29kaW5nIDMsIDM2MHAzMA0KDQpUaGVzZSB3b3VsZCBwcm92 aWRlIGFkZGl0aW9uYWwgY29uc3RyYWludHMgb24gd2hhdCBjb3VsZCBiZSBzZW50IGZvciBl YWNoIHN0cmVhbTsgdGhleSBjb3VsZCBvbmx5IGxvd2VyIChub3QgcmFpc2UpIHRoZSBjb25z dHJhaW50cyBleHByZXNzZWQgaW4gU0RQLiBPbiB0aGUgcGx1cyBzaWRlLCB0aGUgJ2VuY29k aW5ncyBpbiBDTFVFJyBhcHByb2FjaCB3aWxsIG1lYW4gd2UgbmVlZCB0byBjcmVhdGUgc3lu dGF4IHRvIGV4cHJlc3MgY29kZWMtc3BlY2lmaWMgZW5jb2RlciBsaW1pdGF0aW9ucyBmb3Ig dGhlIEFkdmVydGlzZSBtZXNzYWdlcywgYW5kIG11Y2ggb2YgdGhhdCBzeW50YXggY291bGQg dXNlIGhlcmUuIE9uIHRoZSBtaW51cyBzaWRlLCB0aGlzIG1lYW5zIHJlcGxpY2F0aW5nIGZ1 bmN0aW9uYWxpdHkgdGhhdCBpcyBhbHJlYWR5IHBhcnQgb2YgU0RQLg0KDQpJZiB3ZSBkb24n dCB3YW50IHRvIGdvIGRvd24gdGhlIHJvdXRlIG9mIHJlLWV4cHJlc3NpbmcgY29kZWMgbGlt aXRzIGluIENMVUUgdGhlcmUgaXMgYW5vdGhlciBvcHRpb24sIHdoaWNoIGlzIHRoYXQgcmVj ZWl2ZXJzIHRoYXQgd2FudCB0byBleHByZXNzIGRpZmZlcmVudCByZWNlaXZlIGxpbWl0cyBm b3IgZGlmZmVyZW50IGNhcHR1cmUgZW5jb2RpbmdzIHRoZXkgd2lzaCB0byByZWNlaXZlIHdp bGwgbmVlZCB0byBjcmVhdGUgbmV3IG0tbGluZXMgaW4gdGhlIFNEUCBzbyB0aGV5IGNhbiBk aWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIGNhcHR1cmUgZW5jb2RpbmdzIHRoZXkgd2FudCB0 byByZWNlaXZlLiBUaGUgcGx1cyBzaWRlIG9mIHRoaXMgYXBwcm9hY2ggaXMgdGhhdCB0aGlz IGlzIGEgcmVxdWlyZW1lbnQgb2YgdGhlICdFbmNvZGluZ3MgaW4gQ0xVRScgYXBwcm9hY2gg YW55d2F5LCBhcyBpdCdzIG5lZWRlZCBmb3IgdGhlIGNhc2Ugd2hlcmUgdGhlIGluaXRpYWwg YW5zd2VyZXIgaXMgYSBkaXNhZ2dyZWdhdGVkIHN5c3RlbSB0aGF0IGRvZXNuJ3Qgd2FudCB0 byBtdWx0aXBsZXggdGhlaXIgc3RyZWFtczsgdGhlc2Ugc2NlbmFyaW9zIHdpbGwgYWxzbyBu ZWVkIHRvIHJlb2ZmZXIgd2l0aCBuZXcgbS1saW5lcyBhbmQgc3BsaXQgdXAgdGhlIHN0cmVh bXMuDQoNClRoZSBkb3duc2lkZSBvZiB0aGlzIGFwcHJvYWNoIGlzIHRoYXQgY29taW5nIHVw IHdpdGggYSBnZW5lcmFsIHdheSB0byBtaXggYW5kIG1hdGNoIG11bHRpcGxlIG0tbGluZSBl YWNoIG9mIHdoaWNoIG1heSBtdWx0aXBsZXggZGlmZmVyZW50IHN0cmVhbXMsIGFuZCB0aGUg YWJpbGl0eSB0byBjaGFuZ2UgdGhlIHRoZSBudW1iZXIgb2YgbS1saW5lcyBpbiB1c2UgYW5k IHdoaWNoIGVuY29kaW5ncyBhcmUgbXVsdGlwbGV4ZWQgb250byBlYWNoIGlzIHBhaW5mdWws IHRvIHRoZSBwb2ludCB3aGVyZSBJIGRvbid0IGhhdmUgYSBwYXJ0aWN1bGFybHkgZ29vZCBo YW5kbGUgb24gaXQuIEkndmUgaW5jbHVkZWQgc29tZSBpbml0aWFsIHNwZWN1bGF0aW9uIGlu IGFuIGFwcGVuZGl4IGF0IHRoZSBlbmQgb2YgdGhlIHBhZ2UgdG8gYXZvaWQgZWF0aW5nIHVw IHRvbyBtdWNoIHNwYWNlIGhlcmUuDQoNCkFkdmFudGFnZXMgb2YgJ0VuY29kaW5ncyBpbiBD TFVFJyByZWxhdGl2ZSB0byAnRW5jb2RpbmdzIGluIFNEUCc6DQoqICdFbmNvZGluZ3MgaW4g U0RQJyBhcHByb2FjaCBjYW4ndCBleHByZXNzIGFsbCBILjI2NCBzZW5kIGxpbWl0YXRpb25z IHVzaW5nIGV4aXN0aW5nIFNEUCBzeW50YXgNCiogSW4gdGhlIHN0cmFpZ2h0Zm9yd2FyZCBt dWx0aXBsZXhlZCBjYXNlIGZld2VyIChvciBubykgYWRkaXRpb25hbCBPL0FzIGFuZCBtLWxp bmVzDQoNCkRpc2FkdmFudGFnZXM6DQoqIE5lZWQgdG8gcmVpbnZlbnQgc3ludGF4IHRvIGV4 cHJlc3MgSDI2NCAoYW5kIGFueSBvdGhlciBjb2RlYykgbGltaXRhdGlvbnMNCiogUHJvYmxl bXMgd2l0aCBtb3ZpbmcgZnJvbSBtdWx0aXBsZXhlZCB0byBub24tbXVsdGlwbGV4ZWQgKGFu ZCBzaW1pbGFyKQ0KKiBNZWRpYS1zcGVjaWZpYyBpbmZvcm1hdGlvbiBpbiBDTFVFIG1lc3Nh Z2luZywgcG90ZW50aWFsbHkgbGltaXRpbmcgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVy IG9uZ29pbmcgbXVsdGlzdHJlYW0gd29yaw0KDQoqKiogRW5jb2RpbmcgQ29uc3RyYWludHMg aW4gQ0xVRSAqKioNCg0KVGhpcyBzY2VuYXJpbyBwcmVzZW50cyBhIGhhbGYtd2F5IGhvdXNl IGJldHdlZW4gdGhlICdFbmNvZGluZ3MgaW4gQ0xVRScgYXBwcm9hY2ggZXhwcmVzc2VkIGFi b3ZlIGFuZCB0aGUgJ0VuY29kaW5ncyBpbiBTRFAnIGFwcHJvYWNoIGV4cHJlc3NlZCBpbiBk cmFmdC1reXppdmF0LWNsdWUtc2lnbmFsaW5nLiBJbiB0aGlzIGNhc2UgdGhlcmUgaXMgYSBz ZXBlcmF0ZSBtLWxpbmUgcGVyIHN0cmVhbSwganVzdCBhcyB3aXRoIHRoZSAnRW5jb2Rpbmdz IGluIFNEUCcgYXBwcm9hY2guIEhvd2V2ZXIsIGluIHRoaXMgYXBwcm9hY2ggdGhlIGVuY29k aW5nIGNvbnN0cmFpbnRzIGFyZSBleHByZXNzZWQgaW4gdGhlIENMVUUgQWR2ZXJ0aXNtZW50 Lg0KDQpMZXQgdXMgZXhwbG9yZSB0aGUgdGhyZWUtc2NyZWVuIGV4YW1wbGUgZnJvbSBiZWZv cmUgd2l0aCB0aGlzIG5ldyBhcHByb2FjaC4gVGhlcmUgd2lsbCBiZSBhbiBpbml0aWFsIFNE UCBPL0EgdG8gZXN0YWJsaXNoIHRoZSBDTFVFIGNoYW5uZWwgYW5kIHZlcmlmeSB0aGF0IGJv dGggc2lkZXMgc3VwcG9ydCBDTFVFLiBUaGVyZSBpcyB0aGVuIGEgbmV3IFNEUCBvZmZlciB3 aXRoIGFuIG0tbGluZSBwZXIgc3RyZWFtIGF2YWlsYWJsZSwgYW5kIGEgbWF0Y2hpbmcgYWR2 ZXJ0aXNtZW50Og0KDQpFWEFNUExFIFNEUCBPRkZFUiAoZnJvbSBBKQ0KbT12aWRlbyAuLi4N Ci4uLiBIMjY0QDcyMHAzMA0KYT1sYWJlbDpBDQphPXNlbmRyZWN2DQptPXZpZGVvIC4uLg0K Li4uIEgyNjRANzIwcDMwDQphPWxhYmVsOkINCmE9c2VuZHJlY3YNCm09dmlkZW8gLi4uDQou Li4gSDI2NEA3MjBwMzANCmE9bGFiZWw6Qw0KYT1zZW5kcmVjdg0KDQpFWEFNUExFIEFEVkVS VElTTUVOVCAoZnJvbSBBKQ0KIENhcHR1cmUgU2NlbmUgMToNCiAgQ2FwdHVyZSAxOiBMZWZ0 IChFbmNvZGluZyBHcm91cCAxKQ0KICBDYXB0dXJlIDI6IENlbnRlciAoRW5jb2RpbmcgR3Jv dXAgMSkNCiAgQ2FwdHVyZSAzOiBSaWdodCAoRW5jb2RpbmcgR3JvdXAgMSkNCiAgQ2FwdHVy ZSA0OiBTd2l0Y2hlZA0KICBDYXB0dXJlIFNjZW5lIEVudHJ5IDE6IDEsMiwzDQogIENhcHR1 cmUgU2NlbmUgRW50cnkgMjogNA0KICBTaW11bHRhbmVvdXMgU2V0czogMSwyLDMsNA0KIEVu Y29kaW5nIEdyb3VwIDE6DQogIEVuY29kaW5nIDE6IEgyNjQsIDEwODBwMzAsIGxhYmVsPUEN CiAgRW5jb2RpbmcgMjogSDI2NCwgMTA4MHAzMCwgbGFiZWw9Qg0KICBFbmNvZGluZyAzOiBI MjY0LCAxMDgwcDMwLCBsYWJlbD1DDQoNCkkndmUgdXNlZCBsYWJlbCBhYm92ZSB0byB0aWUg dGhlIGVuY29kaW5ncyB0byB0aGUgbS1saW5lcywgYnV0IHRoaXMgY291bGQgYWx0ZXJuYXRl bHkgYmUgU1NSQyAoaWYgU1NSQyB3YXMgYmVpbmcgdXNlZCksIGFwcElkIChpZiBhcHBJZCB3 ZXJlIGJlaW5nIHVzZWQpIG9yIGFueXRoaW5nIGVsc2UuDQoNClRoaXMgY2xvc2VseSBtYXRj aGVzIHRoZSBleGFtcGxlcyBpbiBkcmFmdC1reXppdmF0LWNsdWUtc2lnbmFsaW5nLiBIb3dl dmVyLCB0aGUgc2VuZGVyIGNhbiB1c2UgJ3NlbmRyZWN2JyByYXRoZXIgdGhhbiAnc2VuZG9u bHknIGZvciB0aGUgbmV3IG0tbGluZXMgcmF0aGVyIHRoYW4gJ3NlbmRvbmx5JywgYXMgdGhl IGVuY29kZXIgbGltaXRzIGFyZSBleHByZXNzZWQgaW5zdGVhZCBpbiBDTFVFLiBUaGlzIGFs c28gaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCB0aGUgQ0xVRSBzeW50YXggZm9yIHRoZXNlIGxp bWl0cyBhbGxvd3MgdGhlIHByZWNpc2UgSDI2NCBzZW5kIGxpbWl0cyB0byBiZSBleHByZXNz ZWQgKHdoaWxlIFNEUCBsaW1pdHMgd2hpY2ggcGFyYW1ldGVycyBjYW4gYmUgdXNlZCBpbiBI LjI2NCBzZW5kb25seSkuDQoNCklmIHRoZSBmYXIgZW5kIHdhbnRzIHRvIHJlY2VpdmUgdGhl IHRocmVlIHN0YXRpYyBjYXB0dXJlcyB0aGVuIGl0IHNlbmRzIGFuIGFuc3dlciBTRFAgd2hp Y2ggY2FuIGFjY2VwdCB0aG9zZSwgYWxvbmcgd2l0aCBhIENvbmZpZ3VyZSBtZXNzYWdlIHNw ZWNpZnlpbmcgd2hpY2ggY2FwdHVyZXMgaXQgd2FudHMgdG8gcmVjZWl2ZToNCg0KRVhBTVBM RSBTRFAgQU5TV0VSIChmcm9tIEIpDQptPXZpZGVvIC4uLg0KLi4uIEgyNjRANzIwcDMwDQph PXNlbmRyZWN2DQptPXZpZGVvIC4uLg0KLi4uIEgyNjRANzIwcDMwDQphPXNlbmRyZWN2DQpt PXZpZGVvIC4uLg0KLi4uIEgyNjRANzIwcDMwDQphPXNlbmRyZWN2DQoNCkVYQU1QTEUgQ09O RklHVVJBVElPTiAoZnJvbSBCKQ0KIENhcHR1cmUgMSwgRW5jb2RpbmcgMQ0KIENhcHR1cmUg MiwgRW5jb2RpbmcgMg0KIENhcHR1cmUgMywgRW5jb2RpbmcgMw0KDQpUaGUgcmVjZWl2ZXIg bm8gbG9uZ2VyIG5lZWRzIHRvIGV4cHJlc3MgdGhlIHJlY2VpdmUgbGltaXRzIGluIENMVUU7 IHdpdGggYW4gbS1saW5lIHBlciByZWNlaXZlZCBzdHJlYW0gdGhlIHN0YW5kYXJkIFNEUCBw YXJhbWV0ZXJzIGFscmVhZHkgYWxsb3cgZnVsbCBleHByZXNzaW9uIG9mIHRoZSBsaW1pdGF0 aW9ucy4gTm93IGl0IGp1c3QgbmVlZHMgdG8gc3RhdGUgd2hhdCBlbmNvZGluZyBpdCB3YW50 cyB0byB1c2UgZm9yIGVhY2ggY2FwdHVyZSBpdCByZWNlaXZlcy4NCg0KQWxzbywgaW4gdGhl IFNEUCB0aGUgbmV3IG0tbGluZXMgYXJlIG1hcmtlZCBhcyAnc2VuZHJlY3YnOyBpZiB3ZSBj b25zaWRlciB0aGUgb3RoZXIgZGlyZWN0aW9uIChCIHNlbmRpbmdzIHRvIEEpIHRoZW4gaWYg QiBoYXMgdGhyZWUgc3RyZWFtcyBvciBmZXdlciB0aGVuIGl0IHdpbGwgbm90IGhhdmUgdG8g bWFrZSBhIG5ldyBTRFAgb2ZmZXIuIEZvciBpbnN0YW5jZSwgaWYgQiBzdXBwb3J0ZWQgdXAg dG8gdHdvIGVuY29kaW5ncyBpdHMgcmVzcG9uc2UgY291bGQgaW5zdGVhZCBoYXZlIGJlZW46 DQoNCkVYQU1QTEUgU0RQIEFOU1dFUiAoZnJvbSBCKQ0KbT12aWRlbyAuLi4NCi4uLiBIMjY0 QDcyMHAzMA0KYT1zZW5kcmVjdg0KbT12aWRlbyAuLi4NCi4uLiBIMjY0QDcyMHAzMA0KYT1z ZW5kcmVjdg0KbT12aWRlbyAuLi4NCi4uLiBIMjY0QDcyMHAzMA0KYT1yZWN2b25seQ0KDQpB bmQgY291bGQgaW1tZWRpYXRlbHkgc2VuZCBhbiBBZHZlcnRpc21lbnQgd2l0aCBpdHMgY2Fw dHVyZSBhbmQgZW5jb2RpbmcgaW5mb3JtYXRpb24uIEEgbmV3IG9mZmVyIHdvdWxkIGJlIG5l ZWRlZCBpZiBCIGhhZCBtb3JlIGVuY29kaW5ncyB0aGFuIEEsIG9yIGlmIEEgd2FudGVkIHRv IGNoYW5nZSBpdHMgcmVjZWl2ZSBjYXBhYmlsaXRpZXMgYmFzZWQgb24gdGhlIGNhcHR1cmUg ZW5jb2RpbmdzIGl0IHdhbnRlZCBmcm9tIEEuDQoNClRoaXMgYXBwcm9hY2ggaXMgdmVyeSBs aWtlIHRoZSAnRW5jb2RpbmdzIGluIFNEUCcgYXBwcm9hY2gsIHdpdGggdGhlIGZvbGxvd2lu ZyBhZHZhbnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzOg0KDQpBZHZhbnRhZ2VzIHJlbGF0aXZl IHRvICdFbmNvZGluZ3MgaW4gU0RQJzoNCiogJ0VuY29kaW5ncyBpbiBTRFAnIGFwcHJvYWNo IGNhbid0IGV4cHJlc3MgYWxsIEguMjY0IHNlbmQgbGltaXRhdGlvbnMgdXNpbmcgZXhpc3Rp bmcgU0RQIHN5bnRheA0KKiBNYW55IG0tbGluZXMgY2FuIGJlIHNlbmRyZWN2LCBpbiBtYW55 IGNhc2VzIHdpbGwgbmVlZCBmZXdlciBPL0FzDQoNCkRpc2FkdmFudGFnZXM6DQoqIFN0aWxs IG5lZWQgdG8gcmVpbnZlbnQgc3ludGF4IHRvIGV4cHJlc3MgSDI2NCAoYW5kIGFueSBvdGhl ciBjb2RlYykgZW5jb2RpbmcgbGltaXRhdGlvbnMNCg0KKioqIFN1bW1hcnkgKioqDQoNCkFw cGVhbGluZyBhcyB0aGUgJ0VuY29kaW5ncyBpbiBDTFVFJyBjYXNlIGlzIHdoZW4gYWxsIHN0 cmVhbXMgb2YgYSBnaXZlbiBtZWRpYSB0eXBlIGNhbiBiZSBtdWx0aXBsZXhlZCBvbnRvIGEg c2luZ2xlIG0tbGluZSwgdHJlYXRpbmcgU0RQIGFzIGFuICdlbnZlbG9wZScgQ0xVZSBjYW4g c3ViZGl2aWRlLCBJIGRvbid0IGJlbGlldmUgdGhpcyBhcHByb2FjaCBpcyBhY3R1YWxseSBm ZWFzaWJsZS4gQWxzbyBoYXZpbmcgdG8gc3VwcG9ydCB0aGUgbXVsdGlwbGUgbS1saW5lIGNh c2UgYW5kIGJlIGFibGUgdG8gc2Vuc2libHkgY2hhbmdlIHRoZSBudW1iZXIgb2YgbS1saW5l cyBpcyBwYWluZnVsLCB3aGlsZSB0aGUgbmVlZCB0byByZXBsaWNhdGUgcmVjZWl2ZSBjb2Rl YyBsaW1pdHMgaW4gQ0xVRSB0aGF0IGFyZSBhbHJlYWR5IGV4cHJlc3NlZCB2ZXJ5IGNhcGFi bHkgaW4gU0RQIGlzIHVubGlrZWx5IHRvIGJlIHBvcHVsYXIuDQoNCkkgYmVsaWV2ZSB0aGUg J0VuY29kaW5nICpjb25zdHJhaW50cyogaW4gQ0xVRScgYXBwcm9hY2ggaXMgY29uc2lkZXJh Ymx5IG1vcmUgcGxhdXNpYmxlLCB0aG91Z2ggdGhlIHZhcmlhdGlvbiBmcm9tIHRoZSAnRW5j b2RpbmdzIGluIFNEUCcgYXBwcm9hY2ggaXMgZmFpcmx5IHNtYWxsLiBQcmluY2lwbHkgaXQg Y29tZXMgZG93biB0byB3aGV0aGVyIHRoZSB3b3JrIHJlcXVpcmVkIHRvIGRldmVsb3Agc3lu dGF4IHRvIGV4cHJlc3MgdGhlIHNlbmQgbGltaXRzIGZvciB0aGUgdmFyaW91cyBjb2RlY3Mg aW4gQ0xVRSBpcyB3b3J0aCB0aGUgYWRkZWQgYWNjdXJhY3kgb2Ygd2hhdCBjYW4gYmUgZXhw cmVzc2VkIGluIENMVUUgb3ZlciB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFibGUgaW4gU0RQ LCBhbG9uZyB3aXRoIHRoZSBhZHZhbnRhZ2Ugb2YgbGVzcyBuZWVkIHRvIGFkZCBuZXcgbS1s aW5lcyAoYW5kIHRoZSBhc3NvY2lhdGVkIE8vQXMgaW52b2x2ZWQpLg0KDQoqKiogQXBwZW5k aXggKioqDQoNCkxldCB1cyBmaXJzdCBjb25zaWRlciB0aGUgY2FzZSBvZiB3YW50aW5nIHRv IHNwbGl0IGFuIG9mZmVyZWQgc2V0IG9mIHN0cmVhbXMuIFRoZSBzZW5kZXIgKEEpIGNhbiBz ZW5kIHVwIHRvIGZpdmUgY2FwdHVyZSBlbmNvZGluZ3MsIGFuZCBzbyBzZW5kIGFuIFNEUCBv ZmZlciBhbG9uZyB0aGUgbGluZXMgb2Y6DQoNCm09dmlkZW8gLi4uDQouLi4NCmE9c3NyYzox MjM0DQphPXNzcmM6MjM0NQ0KYT1zc3JjOjM0NTYNCmE9c3NyYzo0NTY3DQphPXNzcmM6NTY3 OA0KYT1zZW5kcmVjdg0KDQpUaGUgcmVjZWl2ZXIgKEIpIHdhbnRzIHRvIHJlY2VpdmUgb25l IG9mIHRob3NlIHN0cmVhbXMgb24gb25lIG0tbGluZSwgdGhyZWUgbW9yZSBvbiBhIHNlY29u ZCBtLWxpbmUgYW5kIHRoZSBmaWZ0aCBub3QgYXQgYWxsLiBUaGUgcnVsZXMgb2YgTy9BIG1l YW4gdGhhdCBCIG11c3Qgc2VuZCBhbiBpbml0aWFsIGFuc3dlciB3aXRoIHRoZSBzaW5nbGUg bS1saW5lLCB3aGljaCB3ZSB3b24ndCBpbGx1c3RyYXRlIGhlcmUsIGFuZCB0aGVuIHNlbmQg YSBuZXcgb2ZmZXIuIFNvbWUgbWV0aG9kIG11c3QgYmUgcHJvdmlkZWQgdG8gc2hvdyB3aGF0 IHN0cmVhbXMgYXJlIHRvIGJlIHJlY2VpdmVkIHdoZXJlOyBpbiB0aGlzIGNhc2UgSSdtIHVz aW5nIHRoZSBtYXgtc3NyYyBkcmFmdDoNCg0KbT12aWRlbyAuLi4NCi4uLg0KYT1tYXgtcmVj di1zc3JjOnsqOjF9DQphPXNlbmRyZWN2DQptPXZpZGVvIC4uLg0KLi4uDQphPW1heC1yZWN2 LXNzcmM6eyo6M30NCmE9c2VuZHJlY3YNCm09dmlkZW8gLi4uIDANCg0KQSB3aWxsIHRoZW4g bmVlZCB0byByZW9yZGVyIHRoZWlyIGFsbG9jYXRpb24gb2YgU1NSQ3MgdG8gbS1saW5lcyB0 byBzZW5zaWJseSBmaXQgdGhpcy4gQW5kIGlmIGxhdGVyIGluIHRoZSBjYWxsIEIgZGVjaWRl cyB0aGF0IGl0IG5vdyB3YW50cyB0byBtdWx0aXBsZXggYWxsIG9mIHRoZSBzdHJlYW1zIHRo aXMgd2lsbCBuZWVkIHRvIGJlIGRvbmUgaW4gcmV2ZXJzZSwgd2l0aCBCIHNlbmRpbmcgYSBu ZXcgb2ZmZXIgd2l0aCBvbmx5IG9uZSBhY3RpdmV2aWRlbyAgbS1saW5lIGFuZCBzdWl0YWJs ZSBtYXgtcmVjdi1zc3JjIHZhbHVlIGFuZCBob3BlIHRoYXQgQSB3aWxsIGNvcnJlY3RseSBp bnRlcnByZXQgdGhpcy4gVGhpcyByZWFsbG9jYXRpb24gb2Ygc3RyZWFtcyBiZXR3ZWVuIG0t bGluZXMgaXMgdGhlIHBhcnQgSSB0aGluayB3aWxsIGJlIGRpZmZpY3VsdCB0byBkZWZpbmUg bm9ybWF0aXZlbHku --------------090901000800030905080508-- From spromano@unina.it Tue Oct 8 04:19:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13EA11E819C for ; Tue, 8 Oct 2013 04:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfI-u2ajQaNs for ; Tue, 8 Oct 2013 04:19:30 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4C13911E81A8 for ; Tue, 8 Oct 2013 04:19:27 -0700 (PDT) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r98BJPow025501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Oct 2013 13:19:26 +0200 From: Simon Pietro Romano Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Oct 2013 13:19:25 +0200 References: <20131008111451.25649.16083.idtracker@ietfa.amsl.com> To: CLUE Message-Id: <723B6AAB-FAA6-46CC-A60D-6AD4001E5F4B@unina.it> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [clue] New version of the protocol draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:19:34 -0000 "Better late than never, but never late is (or would be) better"! Cheers, Simon Inizio messaggio inoltrato: > Da: IETF I-D Submission Tool > Oggetto: Confirmation for Auto-Post of I-D draft-presta-clue-protocol > Data: 08 ottobre 2013 13:14:51 GMT+02:00 > A: Roberta Presta , Simon Romano = >=20 >=20 > Hi, >=20 > The IETF datatracker draft submission service has received your draft > draft-presta-clue-protocol-02, and requires a > confirmation step in order to be able to complete the posting of > the draft. >=20 > Please follow this link to the page where you can confirm the posting: > Confirmation URL: = http://datatracker.ietf.org/submit/status/54393/confirm/ffc62f1e48e9df69fa= 572f745a854ad363f3b2b5/ >=20 >=20 > Best regards, >=20 > The IETF Secretariat > through the draft submission service >=20 >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ From spromano@unina.it Tue Oct 8 04:21:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488D411E81B0 for ; Tue, 8 Oct 2013 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaa7+ehxSw97 for ; Tue, 8 Oct 2013 04:21:25 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 268A721E8189 for ; Tue, 8 Oct 2013 04:21:12 -0700 (PDT) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r98BLBHG005548 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 8 Oct 2013 13:21:11 +0200 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_84DB9FC2-E347-4BF6-8B9C-99980DA6B489" Date: Tue, 8 Oct 2013 13:21:11 +0200 References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> To: CLUE Message-Id: <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 11:21:35 -0000 --Apple-Mail=_84DB9FC2-E347-4BF6-8B9C-99980DA6B489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 ...here it is. Simon Inizio messaggio inoltrato: > Da: internet-drafts@ietf.org > Oggetto: New Version Notification for = draft-presta-clue-protocol-02.txt > Data: 08 ottobre 2013 13:20:31 GMT+02:00 > A: Roberta Presta , Simon Pietro Romano = , Simon Romano >=20 >=20 > A new version of I-D, draft-presta-clue-protocol-02.txt > has been successfully submitted by Roberta Presta and posted to the > IETF repository. >=20 > Filename: draft-presta-clue-protocol > Revision: 02 > Title: CLUE protocol > Creation date: 2013-10-08 > Group: Individual Submission > Number of pages: 26 > URL: = http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt > Status: = http://datatracker.ietf.org/doc/draft-presta-clue-protocol > Htmlized: = http://tools.ietf.org/html/draft-presta-clue-protocol-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-presta-clue-protocol-02 >=20 > Abstract: > The CLUE protocol is an application protocol conceived for the > description and negotiation of a CLUE telepresence session. The > design of the CLUE protocol takes into account the requirements and > the framework defined, respectively, in [I-D.ietf-clue-framework] = and > [I-D.ietf-clue-telepresence-requirements]. The companion document > [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as > well as on the SIP/SDP session establishment phase. We herein focus > on the application level perspective. Message details, together = with > the behavior of both the Media Provider and the Media Consumer are > discussed. >=20 >=20 >=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 > The IETF Secretariat >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_84DB9FC2-E347-4BF6-8B9C-99980DA6B489 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Oggetto: New Version Notification for = draft-presta-clue-protocol-02.txt
Data: 08 ottobre 2013 = 13:20:31 GMT+02:00
A: Roberta Presta <roberta.presta@unina.it>, = Simon Pietro Romano <spromano@unina.it>, Simon = Romano <spromano@unina.it>


A new version of I-D, = draft-presta-clue-protocol-02.txt
has been successfully submitted by = Roberta Presta and posted to the
IETF = repository.

Filename: = draft-presta-clue-protocol
Revision: 02
Title: CLUE = protocol
Creation date: 2013-10-08
Group: = Individual Submission
Number of pages: 26
URL: =             http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt=
Status:          http:/= /datatracker.ietf.org/doc/draft-presta-clue-protocol
Htmlized: =        http://t= ools.ietf.org/html/draft-presta-clue-protocol-02
Diff: =            = http://www.ietf.org/rfcdiff?url2=3Ddraft-presta-clue-protocol-02
Abstract:
  The CLUE protocol is an application protocol = conceived for the
  description and negotiation of a CLUE = telepresence session.  The
  design of the CLUE = protocol takes into account the requirements and
  the = framework defined, respectively, in [I-D.ietf-clue-framework] and
=   [I-D.ietf-clue-telepresence-requirements].  The = companion document
  [I-D.kyzivat-clue-signaling] delves = into CLUE signaling details, as
  well as on the SIP/SDP = session establishment phase.  We herein focus
  on = the application level perspective.  Message details, together = with
  the behavior of both the Media Provider and the = Media Consumer are
  discussed.




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.

The IETF = Secretariat



      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_84DB9FC2-E347-4BF6-8B9C-99980DA6B489-- From rohanse2@cisco.com Tue Oct 8 11:14:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC1821E8281 for ; Tue, 8 Oct 2013 11:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.799 X-Spam-Level: X-Spam-Status: No, score=-8.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6kijNEmxivz for ; Tue, 8 Oct 2013 11:14:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7C46421E8280 for ; Tue, 8 Oct 2013 11:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17529; q=dns/txt; s=iport; t=1381256077; x=1382465677; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NR7dJzBgafG9oiEgL40ktT3YR/8G4jYI7xVo/f9SN3o=; b=XEwceIfjoxAQYpRurwcWPZ2ZVLQaaq+Wmze/cEFk6qLiukeqVqiMV4/t +frO5IR3W7e5vfwGWYAMJmaxju9LFhm2F1D7Wz81TZ3YbTozq4SbdIQNe v711qbPp4xovXxhuS7tp3KKBoGQ2xSUZLpjtZeiG1TDVjK8C4WKSSWBEq w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAIdKVFKQ/khM/2dsb2JhbABZgwc4wXeBIhZ0giUBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTATBgIBAReHawy6dgSNeQuBOQyEIwOYAYY2hBaHNIMlO4EsAQQCAhc X-IronPort-AV: E=Sophos;i="4.90,1057,1371081600"; d="scan'208";a="87269952" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Oct 2013 18:14:35 +0000 Received: from [10.47.196.64] ([10.47.196.64]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r98IEU9b017181 for ; Tue, 8 Oct 2013 18:14:31 GMT Message-ID: <52544BB9.7060403@cisco.com> Date: Tue, 08 Oct 2013 19:15:21 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <5253C3C5.6080207@cisco.com> In-Reply-To: <5253C3C5.6080207@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 18:14:44 -0000 The previous was an attempt at a relatively objective look at the different syntactic options for conveying encoding information in CLUE. However, I do have opinions on the options available. The proposal for negotiating both encodings and multiplexing behaviour in CLUE was included because it's something we have discussed heavily in the past. However there were good reason we moved away from it - it provides a CLUE-specific method of multiplexing that won't play well with the syntax being defined in the wider MMUSIC sphere, as well as all the problems inhereit with multiplexing on a single m-line. The other two options explored use SDP for multiplexing, but one expressed the encoding limitations in SDP while the other does so in CLUE. I think both are workable solutions, but my preference is for the SDP option. While the expressing encoding limitations in CLUE approach does provide a number of advantages: fewer m-lines, fewer O/As, more accurate encoder limitations and (as Paul pointed out in the design call today) the ability to express encoder limitations without committing resources, I think the need to come up with syntax for the encoding limits in CLUE is a painful one. If these limits can be expressed in abstract, codec-independent ways then that's one thing, but each time this issue comes up somewhere the upshot seems to be that abstract, codec-independent limitations aren't actually possible, and that would leave us with the need to reinvent syntax for any codec that could be used. I'd be very happy to be proved wrong about this, but I don't think the advantages of expressing the encoding constraints in CLUE are sufficient to outweight the cost of such codec-specific work, and I don't think we'll be able to come up with a nice abstraction everyone will sign off on. Rob On 08/10/2013 09:35, Robert Hansen wrote: > At the design meeting last week I volunteered to take a stab at > evaluating alternate approaches to conveying all encoding information in > SDP. The text got a bit long for an email, so I've also attached it as a > text document. I'll also put together some slides on the topic for this > call this afternoon. > > One of the fundamental issues we have in clue is how to negotiate the > details of the encodings defined in draft-ietf-clue-framework. Unless > other entities such as captures, which are unique to CLUE, encodings > share many properties with limits that are currently expressible in SDP, > but have additional requirements and limits that are less good fits for > SDP. One of the > > The current assumption we have been working from, as detailed in > draft-kyzivat-clue-signaling, is that the encodings (defined in > draft-ietf-clue-framework), will be expressed in SDP and not in the CLUE > signalling. However, this has only ever been a working assumption rather > than something we've reached consensus on, and this is a fundamental > design decision that impacts not just the message syntax but also the > call flows and state machines inherent in the signalling. As such, I > volunteered to examine the alternative approach, to hopefully allow us > to resolve this issue so we can move forward. > > To do this I am going to examine two alternate options (for deails of > the SDP approach see draft-kyzivat-clue-signaling). One is to, where > possible, negotiate the limits and use of multiple video and audio > subsessions as part of the CLUE Advertisment/Configure exchange, with > the negotiated SDP m-lines treated as an 'envelope' subdivided by CLUE; > this approach was the one that had more initial exploration by the CLUE > WG before we moved towards the SDP approach. The other approach is a > half-way house that has not yet been explored in any detail; this is to > negotiate each channel in SDP, but to express the encoding constraints > within the CLUE signalling. > > *** Encodings in CLUE *** > > In this approach the encodings available, and the constraints associated > with them, are expressed in the CLUE Advertisment. The far end then > selects which encodings they wish to receive, and the limits on those > encodings as part of the CLUE Configure message. > > In the simplest (and, most likely, commonest case) this would allow a > single sendrecv m-line per media type to be used for all sent and > received CLUE-controlled streams. The various streams must then be > demultiplexed; this can be done via explicit SSRC for static streams or > via an additional header such as appId. SSRC is used in examples; > replacing these with appId indicators should be roughly equivalent for > streams with dynamic SSRCs. As such the initial SDP, and then > Advertiment, might look something like: > > EXAMPLE SDP OFFER (from A) > m=video ... > ... > a=ssrc:1234 > a=ssrc:2345 > a=ssrc:3456 > a=sendrecv > > EXAMPLE ADVERTISMENT (from A) > Capture Scene 1: > Capture 1: Left (Encoding Group 1) > Capture 2: Center (Encoding Group 1) > Capture 3: Right (Encoding Group 1) > Capture 4: Switched > Capture Scene Entry 1: 1,2,3 > Capture Scene Entry 2: 4 > Simultaneous Sets: 1,2,3,4 > Encoding Group 1: > Encoding 1: H264, 1080p30, ssrc=1234 > Encoding 2: H264, 1080p30, ssrc=2345 > Encoding 3: H264, 1080p30, ssrc=3456 > > The SSRC/appId attributes are ignorable and hence sendable in the > initial SSRC, though implementations may prefer to leave them out > initially and then readvertise once CLUE is established. > > I've also included SSRCs alongside the encodings. In this case all > encodings are on the same m-line, but there are scenarios where this > multiplexing may not be appropriate or even possible, such as the > disaggregated case when different streams must be sent to different IP > addresses. In such circumstances there is a need to be able to > distinguish which encodings can be sent on which m-line. An alternative > would be to have the SSRCs only in SDP, and use something else to tie > that to the encodings (such as a label attribute). > > Having the encodings split across multiple m-lines will present > additional challenges, which will be detailed later. For now, consider > the rest of the simple case. The far end will complete the SDP > negotiation, and send a Configure message choosing what to receive, > something like this: > > EXAMPLE SDP ANSWER (from B) > m=video ... > ... H264@720p30 > a=sendrecv > > EXAMPLE CONFIGURATION (from B) > Capture 1, Encoding 1 > Capture 2, Encoding 2 > Capture 3, Encoding 3 > > At this point the sender can begin sending three media streams, which > the receiver can demultiplex by SSRC. > > However, one major issue remains even for the multiplexed case: how to > express receiver encode limitations. These are currently expressed in > SDP, and are defined to apply to a single media stream. However, in the > case above three streams are being sent to that port, and we have to > decide what those limits mean. > > One answer would be that it provides the *overall* limit, but this > quickly runs into problems. One issue is that not all parameters can be > sensibly subdivided: for H264 max-br and max-mbps could be divided into > three relatively easily, but max-fs makes less sense. And even avoiding > this, it would allow the far end to validly send a single stream that > matched the combined limit, which the receiver might not be able to cope > with; existing 3-screen systems often have three seperate decoders that > cannot pool their decode resource (eg, they might be able to decode > three 720p streams, but not one 1080p stream). > > As such a better answer is that the SDP receive limits express the limit > for *any* individual stream; in the example above each of the three > streams could be sent at up to 720p30. However, this still poses an > issue: what happens if the receiver wants to receive different capture > encodings with different constraints. In the example above most > receivers will probably want all three streams at similar resolutions, > but in the scenario where a device wants to receive one primary capture > encoding to view full-screne and six capture-encodings to use as small > picture-in-picture insets then the receiver needs to be able to express > these different constraints. > > One option is for the SDP codec limit to provide a set of maxima for any > given stream, but then be able to express *additional* limits for each > capture encoding as part of the Configure message; a highly simplified > version might look like this: > > EXAMPLE CONFIGURATION (from B) > Capture 1, Encoding 1, 720p30 > Capture 2, Encoding 2, 360p30 > Capture 3, Encoding 3, 360p30 > > These would provide additional constraints on what could be sent for > each stream; they could only lower (not raise) the constraints expressed > in SDP. On the plus side, the 'encodings in CLUE' approach will mean we > need to create syntax to express codec-specific encoder limitations for > the Advertise messages, and much of that syntax could use here. On the > minus side, this means replicating functionality that is already part of > SDP. > > If we don't want to go down the route of re-expressing codec limits in > CLUE there is another option, which is that receivers that want to > express different receive limits for different capture encodings they > wish to receive will need to create new m-lines in the SDP so they can > differentiate between the capture encodings they want to receive. The > plus side of this approach is that this is a requirement of the > 'Encodings in CLUE' approach anyway, as it's needed for the case where > the initial answerer is a disaggregated system that doesn't want to > multiplex their streams; these scenarios will also need to reoffer with > new m-lines and split up the streams. > > The downside of this approach is that coming up with a general way to > mix and match multiple m-line each of which may multiplex different > streams, and the ability to change the the number of m-lines in use and > which encodings are multiplexed onto each is painful, to the point where > I don't have a particularly good handle on it. I've included some > initial speculation in an appendix at the end of the page to avoid > eating up too much space here. > > Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': > * 'Encodings in SDP' approach can't express all H.264 send limitations > using existing SDP syntax > * In the straightforward multiplexed case fewer (or no) additional O/As > and m-lines > > Disadvantages: > * Need to reinvent syntax to express H264 (and any other codec) limitations > * Problems with moving from multiplexed to non-multiplexed (and similar) > * Media-specific information in CLUE messaging, potentially limiting > interoperability with other ongoing multistream work > > *** Encoding Constraints in CLUE *** > > This scenario presents a half-way house between the 'Encodings in CLUE' > approach expressed above and the 'Encodings in SDP' approach expressed > in draft-kyzivat-clue-signaling. In this case there is a seperate m-line > per stream, just as with the 'Encodings in SDP' approach. However, in > this approach the encoding constraints are expressed in the CLUE > Advertisment. > > Let us explore the three-screen example from before with this new > approach. There will be an initial SDP O/A to establish the CLUE channel > and verify that both sides support CLUE. There is then a new SDP offer > with an m-line per stream available, and a matching advertisment: > > EXAMPLE SDP OFFER (from A) > m=video ... > ... H264@720p30 > a=label:A > a=sendrecv > m=video ... > ... H264@720p30 > a=label:B > a=sendrecv > m=video ... > ... H264@720p30 > a=label:C > a=sendrecv > > EXAMPLE ADVERTISMENT (from A) > Capture Scene 1: > Capture 1: Left (Encoding Group 1) > Capture 2: Center (Encoding Group 1) > Capture 3: Right (Encoding Group 1) > Capture 4: Switched > Capture Scene Entry 1: 1,2,3 > Capture Scene Entry 2: 4 > Simultaneous Sets: 1,2,3,4 > Encoding Group 1: > Encoding 1: H264, 1080p30, label=A > Encoding 2: H264, 1080p30, label=B > Encoding 3: H264, 1080p30, label=C > > I've used label above to tie the encodings to the m-lines, but this > could alternately be SSRC (if SSRC was being used), appId (if appId were > being used) or anything else. > > This closely matches the examples in draft-kyzivat-clue-signaling. > However, the sender can use 'sendrecv' rather than 'sendonly' for the > new m-lines rather than 'sendonly', as the encoder limits are expressed > instead in CLUE. This also has the advantage that the CLUE syntax for > these limits allows the precise H264 send limits to be expressed (while > SDP limits which parameters can be used in H.264 sendonly). > > If the far end wants to receive the three static captures then it sends > an answer SDP which can accept those, along with a Configure message > specifying which captures it wants to receive: > > EXAMPLE SDP ANSWER (from B) > m=video ... > ... H264@720p30 > a=sendrecv > m=video ... > ... H264@720p30 > a=sendrecv > m=video ... > ... H264@720p30 > a=sendrecv > > EXAMPLE CONFIGURATION (from B) > Capture 1, Encoding 1 > Capture 2, Encoding 2 > Capture 3, Encoding 3 > > The receiver no longer needs to express the receive limits in CLUE; with > an m-line per received stream the standard SDP parameters already allow > full expression of the limitations. Now it just needs to state what > encoding it wants to use for each capture it receives. > > Also, in the SDP the new m-lines are marked as 'sendrecv'; if we > consider the other direction (B sendings to A) then if B has three > streams or fewer then it will not have to make a new SDP offer. For > instance, if B supported up to two encodings its response could instead > have been: > > EXAMPLE SDP ANSWER (from B) > m=video ... > ... H264@720p30 > a=sendrecv > m=video ... > ... H264@720p30 > a=sendrecv > m=video ... > ... H264@720p30 > a=recvonly > > And could immediately send an Advertisment with its capture and encoding > information. A new offer would be needed if B had more encodings than A, > or if A wanted to change its receive capabilities based on the capture > encodings it wanted from A. > > This approach is very like the 'Encodings in SDP' approach, with the > following advantages and disadvantages: > > Advantages relative to 'Encodings in SDP': > * 'Encodings in SDP' approach can't express all H.264 send limitations > using existing SDP syntax > * Many m-lines can be sendrecv, in many cases will need fewer O/As > > Disadvantages: > * Still need to reinvent syntax to express H264 (and any other codec) > encoding limitations > > *** Summary *** > > Appealing as the 'Encodings in CLUE' case is when all streams of a given > media type can be multiplexed onto a single m-line, treating SDP as an > 'envelope' CLUe can subdivide, I don't believe this approach is actually > feasible. Also having to support the multiple m-line case and be able to > sensibly change the number of m-lines is painful, while the need to > replicate receive codec limits in CLUE that are already expressed very > capably in SDP is unlikely to be popular. > > I believe the 'Encoding *constraints* in CLUE' approach is considerably > more plausible, though the variation from the 'Encodings in SDP' > approach is fairly small. Principly it comes down to whether the work > required to develop syntax to express the send limits for the various > codecs in CLUE is worth the added accuracy of what can be expressed in > CLUE over what is currently available in SDP, along with the advantage > of less need to add new m-lines (and the associated O/As involved). > > *** Appendix *** > > Let us first consider the case of wanting to split an offered set of > streams. The sender (A) can send up to five capture encodings, and so > send an SDP offer along the lines of: > > m=video ... > ... > a=ssrc:1234 > a=ssrc:2345 > a=ssrc:3456 > a=ssrc:4567 > a=ssrc:5678 > a=sendrecv > > The receiver (B) wants to receive one of those streams on one m-line, > three more on a second m-line and the fifth not at all. The rules of O/A > mean that B must send an initial answer with the single m-line, which we > won't illustrate here, and then send a new offer. Some method must be > provided to show what streams are to be received where; in this case I'm > using the max-ssrc draft: > > m=video ... > ... > a=max-recv-ssrc:{*:1} > a=sendrecv > m=video ... > ... > a=max-recv-ssrc:{*:3} > a=sendrecv > m=video ... 0 > > A will then need to reorder their allocation of SSRCs to m-lines to > sensibly fit this. And if later in the call B decides that it now wants > to multiplex all of the streams this will need to be done in reverse, > with B sending a new offer with only one activevideo m-line and > suitable max-recv-ssrc value and hope that A will correctly interpret > this. This reallocation of streams between m-lines is the part I think > will be difficult to define normatively. > > Rob > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Oct 9 04:03:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5236F21E8119 for ; Wed, 9 Oct 2013 04:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKrxexGmRBCu for ; Wed, 9 Oct 2013 04:03:50 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B621F9FF3 for ; Wed, 9 Oct 2013 04:03:44 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id nc12so417097qeb.2 for ; Wed, 09 Oct 2013 04:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5w3j4FIjQxZVQRpb8MkxolU2kDi29WnuPgviFuPISUo=; b=wLpC2gXwqI0rcQVVymCH1vAz/XinbGreiHqWnqa2GJ33b9SzZ8yiLbO6Oj9PimTB5g hUFkyRQFmqtVYFubCotbqtBJE8RmzeR4RMpOd9U5vQrvQGMv/RsMqsb/XJ1S2TE44B+6 fPJvXGx6xOTt+Uwl/5lmHchXyIrihjeMo++9qtIcQIQXCz605hDUuoqYr7S+2ewCYYVd uLI+g1Aqp+LUL41EDDbGSqbh2NazjFcRUk3Y18xxw5qdhobVP1rmLlGtferOeLAEuIls sUl+ZOfidPe2HOaXCVdN6NTrs9rGw7DRefbi6TtefkVH4AYwUVXAWSeYJ8oy8PNKs9Sy d5Fw== MIME-Version: 1.0 X-Received: by 10.49.53.10 with SMTP id x10mr8456609qeo.46.1381316623828; Wed, 09 Oct 2013 04:03:43 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 9 Oct 2013 04:03:43 -0700 (PDT) In-Reply-To: <52403F44.2060609@unina.it> References: <52403F44.2060609@unina.it> Date: Wed, 9 Oct 2013 06:03:43 -0500 Message-ID: From: Mary Barnes To: Roberta Presta Content-Type: multipart/alternative; boundary=047d7bd766deaf8e4204e84cd69f Cc: "clue@ietf.org" Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 11:03:51 -0000 --047d7bd766deaf8e4204e84cd69f Content-Type: text/plain; charset=ISO-8859-1 Hi Roberta, Thank you for your review comments. I apologize for the delay in responding. I've been traveling for the past 3+ weeks and seem to be processing my emails LIFO. My responses are below [MB]. Thanks, Mary. On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta wrote: > Hi all, > > in the following some comments to the requirements draft. > > > - about the interworking telepresence systems > In the Introduction section (page 3, third paragraph), it is stated > that the purpose of the document is to provide requirements for enabling > interworking between *"SIP-based [RFC3261] telepresence systems"*. We > should describe/define here in a more precise way these systems, by saying > for example that they are "built upon" centralized SIP-based conferencing > systems as defined in RFC4353 (the "conference" definition in the following > refers to this RFC). We should explicitely mention that we are not dealing > with "signaling agnostic" frameworks, if this is the case, i.e. if we > leverage SIP as the only signaling protocol for the basic session > management. > > [MB] Good point. How about something like the following change: OLD: The purpose of this document is to describe the requirements for a specification that enables interworking between different SIP-based [RFC3261] telepresence systems, by exchanging and negotiating appropriate information. NEW: The purpose of this document is to describe the requirements for a specification that enables interworking between different SIP-based [RFC3261] telepresence systems by exchanging and negotiating appropriate information. In the context of these requirements and related solutions, the SIP telepresence systems are expected to support the SIP conferencing framework [RFC 4353] and SIP based conference control [RFC 4579] . > > > > - about dictating architectural choices > In the Introduction section, "*It is not the intention of CLUE to > dictate telepresence architectural and implementation choices.*" I > would propose to erase "architectural choice" and to leave only > "implementation choice". The CLUE framework should provide some reference > architecture for SIP-based telepresence systems in order to let them > interoperate, so I would not say that CLUE is not intended to dictate > architectural choice. > > [MB] I agree. [/MB] > > - "Endpoint" definition > "*Endpoints can be anything from multiscreen/multicamera rooms to > handheld devices.*" > I agree that talking about room/site *controllers*, or something > similar, it is more appropriate. > > [MB] I'll address this one in a separate email since it's come up in other reviews, as well. [/MB] > > > > - about the site characteristics that need to be shared > In the Problem statement section, page 6, last paragraph: "*Characteristics > may include number, placement, capture/render angle, resolution of > cameras and screens, spatial location and audio mixing parameters of > microphones. The telepresence multi-stream work seeks to describe the > sender situation in a way that allows the receiver to render it > realistically, though it may have a different rendering model than** the > sender; and for the receiver to provide information to the sender in > order to help the sender create adequate content for interworking"*. > The last sentence seems to make reference to some rendering features of the > receiver (render angles, resolution of screens) and that sounds a bit in > contrast with the CLUE philosophy, where the media provider does not care > about the rendering capabilities of the media consumer. > > [MB] Yes. I agree - I think we can remove the last part of that sentence and not lose anything as I think the "allows the receiver to render realistically" is the important aspect. [/MB] > > - > > > Minor issues: > > - "*A telepresence session, requires*", comma to be removed > > [MB] Will fix. [/MB] > > - must vs MUST: there are several "must" that are not capitalized > > [MB] I'll make a pass and ensure we are consistent with capitalizations. [/MB] > > On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta wrote: > Hi all, > > in the following some comments to the requirements draft. > > > - about the interworking telepresence systems > In the Introduction section (page 3, third paragraph), it is stated > that the purpose of the document is to provide requirements for enabling > interworking between *"SIP-based [RFC3261] telepresence systems"*. We > should describe/define here in a more precise way these systems, by saying > for example that they are "built upon" centralized SIP-based conferencing > systems as defined in RFC4353 (the "conference" definition in the following > refers to this RFC). We should explicitely mention that we are not dealing > with "signaling agnostic" frameworks, if this is the case, i.e. if we > leverage SIP as the only signaling protocol for the basic session > management. > > > - about dictating architectural choices > In the Introduction section, "*It is not the intention of CLUE to > dictate telepresence architectural and implementation choices.*" I > would propose to erase "architectural choice" and to leave only > "implementation choice". The CLUE framework should provide some reference > architecture for SIP-based telepresence systems in order to let them > interoperate, so I would not say that CLUE is not intended to dictate > architectural choice. > > > - "Endpoint" definition > "*Endpoints can be anything from multiscreen/multicamera rooms to > handheld devices.*" > I agree that talking about room/site *controllers*, or something > similar, it is more appropriate. > > > - about the site characteristics that need to be shared > In the Problem statement section, page 6, last paragraph: "*Characteristics > may include number, placement, capture/render angle, resolution of > cameras and screens, spatial location and audio mixing parameters of > microphones. The telepresence multi-stream work seeks to describe the > sender situation in a way that allows the receiver to render it > realistically, though it may have a different rendering model than**the sender; and for > the receiver to provide information to the sender in order to help the > sender create adequate content for interworking"*. The last sentence > seems to make reference to some rendering features of the receiver (render > angles, resolution of screens) and that sounds a bit in contrast with the > CLUE philosophy, where the media provider does not care about the rendering > capabilities of the media consumer. > > > Minor issues: > > - "*A telepresence session, requires*", comma to be removed > - must vs MUST: there are several "must" that are not capitalized > > > Regards, > > Roberta > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --047d7bd766deaf8e4204e84cd69f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Roberta,

Thank you for your review c= omments. I apologize for the delay in responding. I've been traveling f= or the past 3+ weeks and seem to be processing my emails LIFO.=A0

My responses are below [MB].

Thanks= ,
Mary.


On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta=A0<roberta= .presta@unina.it>=A0wrote:
Hi all,

i= n the following some comments to the requirements draft.

  • about the interworking telepresence systems
    In the Introduct= ion section (page 3, third paragraph), it is stated that the purpose of the= document is to provide requirements for enabling interworking between=A0"SIP-based [RFC3261] telepresence systems". We should descri= be/define here in a more precise way these systems, by saying for example t= hat they are "built upon" centralized SIP-based conferencing syst= ems as defined in RFC4353 (the "conference" definition in the fol= lowing refers to this RFC). We should explicitely mention that we are not d= ealing with "signaling agnostic" frameworks, if this is the case,= i.e. if we leverage SIP as the only signaling protocol for the basic sessi= on management.
[MB] Good point. =A0How about something like t= he following change:
OLD:
=A0 =A0The purpose of th= is document is to describe the requirements for a
=A0 =A0specific= ation that enables interworking between different SIP-based
=A0 =A0[RFC3261] telepresence systems, by exchanging and negotiating
=A0 =A0appropriate information.=A0

= NEW:=A0
=A0 =A0The purpose of this document is to describe t= he requirements for a
=A0 =A0specification that enables interworking between different SIP-b= ased
=A0 =A0[RFC3261] telepresence systems by exchanging and nego= tiating
=A0 =A0appropriate information. =A0In the context of thes= e requirements and related
=A0 =A0solutions, the SIP=A0telepresence systems are expected to suppo= rt the SIP conferencing
=A0 =A0framework [RFC 4353] and SIP based= conference control [RFC 4579] .
=A0 =A0
=A0
    • about dictating = architectural choices
      In the Introduction section, "It is not th= e intention of CLUE to dictate telepresence architectural and implementatio= n choices." I would propose to erase "architectural choice&qu= ot; and to leave only "implementation choice". The CLUE framework= should provide some reference=A0 architecture for SIP-based telepresence s= ystems in order to let them interoperate, so I would not say that CLUE is n= ot intended to dictate architectural choice.=A0
    [MB] I agree. [/MB]=A0
    • "Endpoint" defi= nition
      "Endpoints can be anything from multiscreen/multicamera r= ooms to handheld devices."
      I agree that talking about room/site= *controllers*, or something similar, it is more appropriate.
    [MB] I'll address this one in a separate e= mail since it's come up in other reviews, as well. [/MB]=A0
      • about the site c= haracteristics that need to be shared
        In the Problem statement section, = page 6, last paragraph: "Characteristics may include number, placem= ent, capture/render angle, resolution of cameras and=A0screens, spatial location and audio mixing parameters of microphones. The telepre= sence multi-stream work seeks to describe the sender situation in a way tha= t allows the receiver to render it realistically, though it may have a diff= erent rendering model than=A0the sender; and=A0for the receiver t= o provide information to the sender in order to help the sender create adeq= uate content for interworking". The last sentence seems to mak= e reference to some rendering features of the receiver (render angles, reso= lution of screens) and that sounds a bit in contrast with the CLUE philosop= hy, where the media provider does not care about the rendering capabilities= of the media consumer.
      [MB] Yes. =A0I agree - I think we can rem= ove the last part of that sentence and not lose anything as I think the &qu= ot;allows the receiver to render realistically" is the important aspec= t. =A0[/MB]=A0

      • Minor issues:
        • "A telepresence session, requires"= ;, comma to be removed
      [MB] Will fix. [/MB= ]=A0
      • must vs MUST: there are s= everal "must" that are not capitalized
      [MB] I'll make a pass and ensure we are consistent with capi= talizations. [/MB]=A0

      <= ul>


      On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta <roberta.presta@unina.it> wrote:
      =20 =20 =20
      Hi all,

      in the following some comments to the requirements draft.

      • about the interworking telepresence systems
        In the Introduction section (page 3, third paragraph), it is stated that the purpose of the document is to provide requirements for enabling interworking between "SIP-based [RFC3261] telepresence systems". We should describe/defi= ne here in a more precise way these systems, by saying for example that they are "built upon" centralized SIP-based conferen= cing systems as defined in RFC4353 (the "conference" definitio= n in the following refers to this RFC). We should explicitely mention that we are not dealing with "signaling agnostic" framewo= rks, if this is the case, i.e. if we leverage SIP as the only signaling protocol for the basic session management.
      • about dictating architectural choices
        In the Introduction section, "It is not the intention of CL= UE to dictate telepresence architectural and implementation choices." I would propose to erase "architectural c= hoice" and to leave only "implementation choice". The CLUE frame= work should provide some reference=A0 architecture for SIP-based telepresence systems in order to let them interoperate, so I would not say that CLUE is not intended to dictate architectural choice.
      • "Endpoint" definition
        "Endpoints can be anything from multiscreen/multicamera roo= ms to handheld devices."
        I agree that talking about room/site *controllers*, or something similar, it is more appropriate.
      • about the site characteristics that need to be shared
        In the Problem statement section, page 6, last paragraph: "= Characteristics may include number, placement, capture/render angle, resolution of cameras and screens, spatial location and audio mixing parameters of microphones. The telepresence multi-stream work seeks to describe the sender situation in a way that allows the receiver to render it realistically, though it may have a different rendering model than the sender; and for the receiver to provide information to the sender in order to help the sender create adequate content for interworking". The last sentence seems to make reference to some rendering features of the receiver (render angles, resolution of screens) and that sounds a bit in contrast with the CLUE philosophy, where the media provider does not care about the rendering capabilities of the media consumer.

      Minor issues:
      • "A telepresence session, requires", comma to be = removed
      • must vs MUST: there are several "must" that are not capitalized

      Regards,

      Roberta

      _______________________________________________
      clue mailing list
      clue@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/clue


      --047d7bd766deaf8e4204e84cd69f-- From pkyzivat@alum.mit.edu Wed Oct 9 08:40:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8321F960D for ; Wed, 9 Oct 2013 08:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.68 X-Spam-Level: X-Spam-Status: No, score=0.68 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl7-Bn215T9C for ; Wed, 9 Oct 2013 08:40:31 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 4512B21F940D for ; Wed, 9 Oct 2013 08:40:27 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id b0481m0031ap0As513gSCL; Wed, 09 Oct 2013 15:40:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id b3gS1m00F3ZTu2S3i3gS3o; Wed, 09 Oct 2013 15:40:26 +0000 Message-ID: <525578E9.6010500@alum.mit.edu> Date: Wed, 09 Oct 2013 11:40:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> In-Reply-To: <52544BB9.7060403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381333226; bh=UCP7Ya8iQaI3VKBv028A+H+cFXuXlWwKxp2bzAHESRI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RWb6dxmdoMWL5n26KlHVcYEjg6N5lixETVzofzep1Rq/e7ZkhKVDY2C76Uhw36J57 u1T0ulWkWFkWl/PU152NQlNo7oRmU9/hslm2C3R289S2aE2enF1Pb08AaoO9x/MacG UIDUA0huIQ66Ij03wGUEj+6p9KmNxXhGrcgVEqMlHHEKwMbwV9gbclSsWhtMNzfMub OBGtXLH2ndQAzaw7O97u+PuysVWFo83R5nIWO43+zUqyYlduDBIpiTKGj+ClYdSZF8 kpijDmw9fla0EHKk/SlzWS/1b6WZStLmFYCm33NShFTHBiWnVOuKrKuo122xT6LGjX q2aPTClbYDBNA== Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 15:40:36 -0000 Rob, Thanks for digging into this and getting the discussion started. This is an important decision, so we need some vigorous discussion. I'm looking for feedback from everybody that is actively involved in this. I've been on both sides of this. I've pursued the encoding-in-SDP approach in the signaling document. In part because of the consequences that showed up in doing that I've been pushing the exploration of the alternative(s). Now we have that. With the encoding-in-SDP approach I remain disturbed by the need for the advertiser to commit media resources (ports, bandwidth) for all the encodings it wants to mention in an advertisement. I think this could be quite burdensome, especially for an MCU, that may be advertising many more options than any one endpoint is likely to use. This will be less of a problem with bundling, but it still may be a burden wrt bandwidth commitments. It would be unfortunate if the MCU must limit itself in the number of encodings it offers to avoid the call being blocked for demanding too much bandwidth. OTOH, I appreciate Rob's concern over reinventing syntax for codec specific constraints. There is no perfect answer here - we must pick our poison. I'm not going to make a choice of my own now (maybe ever). I want to see what others say. Thanks, Paul On 10/8/13 2:15 PM, Robert Hansen wrote: > The previous was an attempt at a relatively objective look at the > different syntactic options for conveying encoding information in CLUE. > However, I do have opinions on the options available. > > The proposal for negotiating both encodings and multiplexing behaviour > in CLUE was included because it's something we have discussed heavily in > the past. However there were good reason we moved away from it - it > provides a CLUE-specific method of multiplexing that won't play well > with the syntax being defined in the wider MMUSIC sphere, as well as all > the problems inhereit with multiplexing on a single m-line. > > The other two options explored use SDP for multiplexing, but one > expressed the encoding limitations in SDP while the other does so in > CLUE. I think both are workable solutions, but my preference is for the > SDP option. > > While the expressing encoding limitations in CLUE approach does provide > a number of advantages: fewer m-lines, fewer O/As, more accurate encoder > limitations and (as Paul pointed out in the design call today) the > ability to express encoder limitations without committing resources, I > think the need to come up with syntax for the encoding limits in CLUE is > a painful one. If these limits can be expressed in abstract, > codec-independent ways then that's one thing, but each time this issue > comes up somewhere the upshot seems to be that abstract, > codec-independent limitations aren't actually possible, and that would > leave us with the need to reinvent syntax for any codec that could be used. > > I'd be very happy to be proved wrong about this, but I don't think the > advantages of expressing the encoding constraints in CLUE are sufficient > to outweight the cost of such codec-specific work, and I don't think > we'll be able to come up with a nice abstraction everyone will sign off on. > > Rob > > On 08/10/2013 09:35, Robert Hansen wrote: >> At the design meeting last week I volunteered to take a stab at >> evaluating alternate approaches to conveying all encoding information in >> SDP. The text got a bit long for an email, so I've also attached it as a >> text document. I'll also put together some slides on the topic for this >> call this afternoon. >> >> One of the fundamental issues we have in clue is how to negotiate the >> details of the encodings defined in draft-ietf-clue-framework. Unless >> other entities such as captures, which are unique to CLUE, encodings >> share many properties with limits that are currently expressible in SDP, >> but have additional requirements and limits that are less good fits for >> SDP. One of the >> >> The current assumption we have been working from, as detailed in >> draft-kyzivat-clue-signaling, is that the encodings (defined in >> draft-ietf-clue-framework), will be expressed in SDP and not in the CLUE >> signalling. However, this has only ever been a working assumption rather >> than something we've reached consensus on, and this is a fundamental >> design decision that impacts not just the message syntax but also the >> call flows and state machines inherent in the signalling. As such, I >> volunteered to examine the alternative approach, to hopefully allow us >> to resolve this issue so we can move forward. >> >> To do this I am going to examine two alternate options (for deails of >> the SDP approach see draft-kyzivat-clue-signaling). One is to, where >> possible, negotiate the limits and use of multiple video and audio >> subsessions as part of the CLUE Advertisment/Configure exchange, with >> the negotiated SDP m-lines treated as an 'envelope' subdivided by CLUE; >> this approach was the one that had more initial exploration by the CLUE >> WG before we moved towards the SDP approach. The other approach is a >> half-way house that has not yet been explored in any detail; this is to >> negotiate each channel in SDP, but to express the encoding constraints >> within the CLUE signalling. >> >> *** Encodings in CLUE *** >> >> In this approach the encodings available, and the constraints associated >> with them, are expressed in the CLUE Advertisment. The far end then >> selects which encodings they wish to receive, and the limits on those >> encodings as part of the CLUE Configure message. >> >> In the simplest (and, most likely, commonest case) this would allow a >> single sendrecv m-line per media type to be used for all sent and >> received CLUE-controlled streams. The various streams must then be >> demultiplexed; this can be done via explicit SSRC for static streams or >> via an additional header such as appId. SSRC is used in examples; >> replacing these with appId indicators should be roughly equivalent for >> streams with dynamic SSRCs. As such the initial SDP, and then >> Advertiment, might look something like: >> >> EXAMPLE SDP OFFER (from A) >> m=video ... >> ... >> a=ssrc:1234 >> a=ssrc:2345 >> a=ssrc:3456 >> a=sendrecv >> >> EXAMPLE ADVERTISMENT (from A) >> Capture Scene 1: >> Capture 1: Left (Encoding Group 1) >> Capture 2: Center (Encoding Group 1) >> Capture 3: Right (Encoding Group 1) >> Capture 4: Switched >> Capture Scene Entry 1: 1,2,3 >> Capture Scene Entry 2: 4 >> Simultaneous Sets: 1,2,3,4 >> Encoding Group 1: >> Encoding 1: H264, 1080p30, ssrc=1234 >> Encoding 2: H264, 1080p30, ssrc=2345 >> Encoding 3: H264, 1080p30, ssrc=3456 >> >> The SSRC/appId attributes are ignorable and hence sendable in the >> initial SSRC, though implementations may prefer to leave them out >> initially and then readvertise once CLUE is established. >> >> I've also included SSRCs alongside the encodings. In this case all >> encodings are on the same m-line, but there are scenarios where this >> multiplexing may not be appropriate or even possible, such as the >> disaggregated case when different streams must be sent to different IP >> addresses. In such circumstances there is a need to be able to >> distinguish which encodings can be sent on which m-line. An alternative >> would be to have the SSRCs only in SDP, and use something else to tie >> that to the encodings (such as a label attribute). >> >> Having the encodings split across multiple m-lines will present >> additional challenges, which will be detailed later. For now, consider >> the rest of the simple case. The far end will complete the SDP >> negotiation, and send a Configure message choosing what to receive, >> something like this: >> >> EXAMPLE SDP ANSWER (from B) >> m=video ... >> ... H264@720p30 >> a=sendrecv >> >> EXAMPLE CONFIGURATION (from B) >> Capture 1, Encoding 1 >> Capture 2, Encoding 2 >> Capture 3, Encoding 3 >> >> At this point the sender can begin sending three media streams, which >> the receiver can demultiplex by SSRC. >> >> However, one major issue remains even for the multiplexed case: how to >> express receiver encode limitations. These are currently expressed in >> SDP, and are defined to apply to a single media stream. However, in the >> case above three streams are being sent to that port, and we have to >> decide what those limits mean. >> >> One answer would be that it provides the *overall* limit, but this >> quickly runs into problems. One issue is that not all parameters can be >> sensibly subdivided: for H264 max-br and max-mbps could be divided into >> three relatively easily, but max-fs makes less sense. And even avoiding >> this, it would allow the far end to validly send a single stream that >> matched the combined limit, which the receiver might not be able to cope >> with; existing 3-screen systems often have three seperate decoders that >> cannot pool their decode resource (eg, they might be able to decode >> three 720p streams, but not one 1080p stream). >> >> As such a better answer is that the SDP receive limits express the limit >> for *any* individual stream; in the example above each of the three >> streams could be sent at up to 720p30. However, this still poses an >> issue: what happens if the receiver wants to receive different capture >> encodings with different constraints. In the example above most >> receivers will probably want all three streams at similar resolutions, >> but in the scenario where a device wants to receive one primary capture >> encoding to view full-screne and six capture-encodings to use as small >> picture-in-picture insets then the receiver needs to be able to express >> these different constraints. >> >> One option is for the SDP codec limit to provide a set of maxima for any >> given stream, but then be able to express *additional* limits for each >> capture encoding as part of the Configure message; a highly simplified >> version might look like this: >> >> EXAMPLE CONFIGURATION (from B) >> Capture 1, Encoding 1, 720p30 >> Capture 2, Encoding 2, 360p30 >> Capture 3, Encoding 3, 360p30 >> >> These would provide additional constraints on what could be sent for >> each stream; they could only lower (not raise) the constraints expressed >> in SDP. On the plus side, the 'encodings in CLUE' approach will mean we >> need to create syntax to express codec-specific encoder limitations for >> the Advertise messages, and much of that syntax could use here. On the >> minus side, this means replicating functionality that is already part of >> SDP. >> >> If we don't want to go down the route of re-expressing codec limits in >> CLUE there is another option, which is that receivers that want to >> express different receive limits for different capture encodings they >> wish to receive will need to create new m-lines in the SDP so they can >> differentiate between the capture encodings they want to receive. The >> plus side of this approach is that this is a requirement of the >> 'Encodings in CLUE' approach anyway, as it's needed for the case where >> the initial answerer is a disaggregated system that doesn't want to >> multiplex their streams; these scenarios will also need to reoffer with >> new m-lines and split up the streams. >> >> The downside of this approach is that coming up with a general way to >> mix and match multiple m-line each of which may multiplex different >> streams, and the ability to change the the number of m-lines in use and >> which encodings are multiplexed onto each is painful, to the point where >> I don't have a particularly good handle on it. I've included some >> initial speculation in an appendix at the end of the page to avoid >> eating up too much space here. >> >> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': >> * 'Encodings in SDP' approach can't express all H.264 send limitations >> using existing SDP syntax >> * In the straightforward multiplexed case fewer (or no) additional O/As >> and m-lines >> >> Disadvantages: >> * Need to reinvent syntax to express H264 (and any other codec) >> limitations >> * Problems with moving from multiplexed to non-multiplexed (and similar) >> * Media-specific information in CLUE messaging, potentially limiting >> interoperability with other ongoing multistream work >> >> *** Encoding Constraints in CLUE *** >> >> This scenario presents a half-way house between the 'Encodings in CLUE' >> approach expressed above and the 'Encodings in SDP' approach expressed >> in draft-kyzivat-clue-signaling. In this case there is a seperate m-line >> per stream, just as with the 'Encodings in SDP' approach. However, in >> this approach the encoding constraints are expressed in the CLUE >> Advertisment. >> >> Let us explore the three-screen example from before with this new >> approach. There will be an initial SDP O/A to establish the CLUE channel >> and verify that both sides support CLUE. There is then a new SDP offer >> with an m-line per stream available, and a matching advertisment: >> >> EXAMPLE SDP OFFER (from A) >> m=video ... >> ... H264@720p30 >> a=label:A >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=label:B >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=label:C >> a=sendrecv >> >> EXAMPLE ADVERTISMENT (from A) >> Capture Scene 1: >> Capture 1: Left (Encoding Group 1) >> Capture 2: Center (Encoding Group 1) >> Capture 3: Right (Encoding Group 1) >> Capture 4: Switched >> Capture Scene Entry 1: 1,2,3 >> Capture Scene Entry 2: 4 >> Simultaneous Sets: 1,2,3,4 >> Encoding Group 1: >> Encoding 1: H264, 1080p30, label=A >> Encoding 2: H264, 1080p30, label=B >> Encoding 3: H264, 1080p30, label=C >> >> I've used label above to tie the encodings to the m-lines, but this >> could alternately be SSRC (if SSRC was being used), appId (if appId were >> being used) or anything else. >> >> This closely matches the examples in draft-kyzivat-clue-signaling. >> However, the sender can use 'sendrecv' rather than 'sendonly' for the >> new m-lines rather than 'sendonly', as the encoder limits are expressed >> instead in CLUE. This also has the advantage that the CLUE syntax for >> these limits allows the precise H264 send limits to be expressed (while >> SDP limits which parameters can be used in H.264 sendonly). >> >> If the far end wants to receive the three static captures then it sends >> an answer SDP which can accept those, along with a Configure message >> specifying which captures it wants to receive: >> >> EXAMPLE SDP ANSWER (from B) >> m=video ... >> ... H264@720p30 >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=sendrecv >> >> EXAMPLE CONFIGURATION (from B) >> Capture 1, Encoding 1 >> Capture 2, Encoding 2 >> Capture 3, Encoding 3 >> >> The receiver no longer needs to express the receive limits in CLUE; with >> an m-line per received stream the standard SDP parameters already allow >> full expression of the limitations. Now it just needs to state what >> encoding it wants to use for each capture it receives. >> >> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we >> consider the other direction (B sendings to A) then if B has three >> streams or fewer then it will not have to make a new SDP offer. For >> instance, if B supported up to two encodings its response could instead >> have been: >> >> EXAMPLE SDP ANSWER (from B) >> m=video ... >> ... H264@720p30 >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=sendrecv >> m=video ... >> ... H264@720p30 >> a=recvonly >> >> And could immediately send an Advertisment with its capture and encoding >> information. A new offer would be needed if B had more encodings than A, >> or if A wanted to change its receive capabilities based on the capture >> encodings it wanted from A. >> >> This approach is very like the 'Encodings in SDP' approach, with the >> following advantages and disadvantages: >> >> Advantages relative to 'Encodings in SDP': >> * 'Encodings in SDP' approach can't express all H.264 send limitations >> using existing SDP syntax >> * Many m-lines can be sendrecv, in many cases will need fewer O/As >> >> Disadvantages: >> * Still need to reinvent syntax to express H264 (and any other codec) >> encoding limitations >> >> *** Summary *** >> >> Appealing as the 'Encodings in CLUE' case is when all streams of a given >> media type can be multiplexed onto a single m-line, treating SDP as an >> 'envelope' CLUe can subdivide, I don't believe this approach is actually >> feasible. Also having to support the multiple m-line case and be able to >> sensibly change the number of m-lines is painful, while the need to >> replicate receive codec limits in CLUE that are already expressed very >> capably in SDP is unlikely to be popular. >> >> I believe the 'Encoding *constraints* in CLUE' approach is considerably >> more plausible, though the variation from the 'Encodings in SDP' >> approach is fairly small. Principly it comes down to whether the work >> required to develop syntax to express the send limits for the various >> codecs in CLUE is worth the added accuracy of what can be expressed in >> CLUE over what is currently available in SDP, along with the advantage >> of less need to add new m-lines (and the associated O/As involved). >> >> *** Appendix *** >> >> Let us first consider the case of wanting to split an offered set of >> streams. The sender (A) can send up to five capture encodings, and so >> send an SDP offer along the lines of: >> >> m=video ... >> ... >> a=ssrc:1234 >> a=ssrc:2345 >> a=ssrc:3456 >> a=ssrc:4567 >> a=ssrc:5678 >> a=sendrecv >> >> The receiver (B) wants to receive one of those streams on one m-line, >> three more on a second m-line and the fifth not at all. The rules of O/A >> mean that B must send an initial answer with the single m-line, which we >> won't illustrate here, and then send a new offer. Some method must be >> provided to show what streams are to be received where; in this case I'm >> using the max-ssrc draft: >> >> m=video ... >> ... >> a=max-recv-ssrc:{*:1} >> a=sendrecv >> m=video ... >> ... >> a=max-recv-ssrc:{*:3} >> a=sendrecv >> m=video ... 0 >> >> A will then need to reorder their allocation of SSRCs to m-lines to >> sensibly fit this. And if later in the call B decides that it now wants >> to multiplex all of the streams this will need to be done in reverse, >> with B sending a new offer with only one activevideo m-line and >> suitable max-recv-ssrc value and hope that A will correctly interpret >> this. This reallocation of streams between m-lines is the part I think >> will be difficult to define normatively. >> >> Rob >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From ron.even.tlv@gmail.com Wed Oct 9 10:06:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F221F9FF1 for ; Wed, 9 Oct 2013 10:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRdDWyObr5K1 for ; Wed, 9 Oct 2013 10:06:28 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id EF50821E8129 for ; Wed, 9 Oct 2013 10:06:23 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so1351977pab.13 for ; Wed, 09 Oct 2013 10:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=wFmWv+YVSEoQzt6l4xW1R8IezAQefDBnHXv/LMI2JAY=; b=EwG6EW5ftVSrkIqrjvvZrkfBMvB488ynxrRecVJF0v83imw2n5+pICGs8ombvTrXJz bycqJmOjUfsXHR4lS4ij5FZeRrZ2sdW2Nq1IU0zspIZgtfYjrpJtTAHtlh22zMm7SKAu 3wnFD43JZuUZdklEYr/YIlOhLVtHfFE1NDeu7RaTTChrHWmjqWjNanZx3F3DiSklkSF+ ovFbVAu8JtXLV6d3ZrIg4iyvpM6+1oNGiu42VkFbOfZJc0eC4iBZqzK82bPoyxmkqkLO YaTwVFj5n7r8O9VQHSOv1zpErB6oJhiiYjnGAR1r+SlK/2WBu8TcZwgyG9uFpT3TPtzu 6xvg== X-Received: by 10.66.251.1 with SMTP id zg1mr4231550pac.160.1381338383394; Wed, 09 Oct 2013 10:06:23 -0700 (PDT) Received: from RoniE ([59.37.12.1]) by mx.google.com with ESMTPSA id xe9sm56230207pab.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 09 Oct 2013 10:06:22 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> <525578E9.6010500@alum.mit.edu> In-Reply-To: <525578E9.6010500@alum.mit.edu> Date: Wed, 9 Oct 2013 20:03:11 +0300 Message-ID: <009901cec511$73984d00$5ac8e700$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJW+7BbzecjDmhnuMkm9Y44wC+8lwIrk0xlAlKgxr+YuDd7QA== Content-Language: en-us Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:06:30 -0000 Hi, Some quick points, I still need to look more into the options and I was busy this week and could not attend the Tuesday call. As for Paul concern about the resource allocation when providing the encoding is SDP , I think that this is not an issue since the m-lines specify sendonly streams to be used by the advertisement (section 6 examples of the signaling draft) My general view on the encoding was not favorable from the start. I could not understand why we need the resource management as part of CLUE. My past experience was that trying to optimize resource per each codec is not easy and it is better to use abstract compute units that are codec independent but allow for multiplications of the unit based on capabilities. For example H.264 CIF will be one unit and H.264 HD will use 4 units and VP8 HD will use 4 units (not real numbers just an example), still I am not sure why in CLUE where we wanted to address relations between streams (spatial) we invest so much in resource management. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: 09 October, 2013 6:40 PM > To: clue@ietf.org > Subject: Re: [clue] Expressing encoding information in CLUE > > Rob, > > Thanks for digging into this and getting the discussion started. > This is an important decision, so we need some vigorous discussion. I'm > looking for feedback from everybody that is actively involved in this. > > I've been on both sides of this. I've pursued the encoding-in-SDP approach in > the signaling document. In part because of the consequences that showed > up in doing that I've been pushing the exploration of the alternative(s). Now > we have that. > > With the encoding-in-SDP approach I remain disturbed by the need for the > advertiser to commit media resources (ports, bandwidth) for all the > encodings it wants to mention in an advertisement. I think this could be quite > burdensome, especially for an MCU, that may be advertising many more > options than any one endpoint is likely to use. This will be less of a problem > with bundling, but it still may be a burden wrt bandwidth commitments. It > would be unfortunate if the MCU must limit itself in the number of > encodings it offers to avoid the call being blocked for demanding too much > bandwidth. > > OTOH, I appreciate Rob's concern over reinventing syntax for codec specific > constraints. > > There is no perfect answer here - we must pick our poison. > > I'm not going to make a choice of my own now (maybe ever). I want to see > what others say. > > Thanks, > Paul > > On 10/8/13 2:15 PM, Robert Hansen wrote: > > The previous was an attempt at a relatively objective look at the > > different syntactic options for conveying encoding information in CLUE. > > However, I do have opinions on the options available. > > > > The proposal for negotiating both encodings and multiplexing behaviour > > in CLUE was included because it's something we have discussed heavily > > in the past. However there were good reason we moved away from it - it > > provides a CLUE-specific method of multiplexing that won't play well > > with the syntax being defined in the wider MMUSIC sphere, as well as > > all the problems inhereit with multiplexing on a single m-line. > > > > The other two options explored use SDP for multiplexing, but one > > expressed the encoding limitations in SDP while the other does so in > > CLUE. I think both are workable solutions, but my preference is for > > the SDP option. > > > > While the expressing encoding limitations in CLUE approach does > > provide a number of advantages: fewer m-lines, fewer O/As, more > > accurate encoder limitations and (as Paul pointed out in the design > > call today) the ability to express encoder limitations without > > committing resources, I think the need to come up with syntax for the > > encoding limits in CLUE is a painful one. If these limits can be > > expressed in abstract, codec-independent ways then that's one thing, > > but each time this issue comes up somewhere the upshot seems to be > > that abstract, codec-independent limitations aren't actually possible, > > and that would leave us with the need to reinvent syntax for any codec > that could be used. > > > > I'd be very happy to be proved wrong about this, but I don't think the > > advantages of expressing the encoding constraints in CLUE are > > sufficient to outweight the cost of such codec-specific work, and I > > don't think we'll be able to come up with a nice abstraction everyone will > sign off on. > > > > Rob > > > > On 08/10/2013 09:35, Robert Hansen wrote: > >> At the design meeting last week I volunteered to take a stab at > >> evaluating alternate approaches to conveying all encoding information > >> in SDP. The text got a bit long for an email, so I've also attached > >> it as a text document. I'll also put together some slides on the > >> topic for this call this afternoon. > >> > >> One of the fundamental issues we have in clue is how to negotiate the > >> details of the encodings defined in draft-ietf-clue-framework. Unless > >> other entities such as captures, which are unique to CLUE, encodings > >> share many properties with limits that are currently expressible in > >> SDP, but have additional requirements and limits that are less good > >> fits for SDP. One of the > >> > >> The current assumption we have been working from, as detailed in > >> draft-kyzivat-clue-signaling, is that the encodings (defined in > >> draft-ietf-clue-framework), will be expressed in SDP and not in the > >> CLUE signalling. However, this has only ever been a working > >> assumption rather than something we've reached consensus on, and this > >> is a fundamental design decision that impacts not just the message > >> syntax but also the call flows and state machines inherent in the > >> signalling. As such, I volunteered to examine the alternative > >> approach, to hopefully allow us to resolve this issue so we can move > forward. > >> > >> To do this I am going to examine two alternate options (for deails of > >> the SDP approach see draft-kyzivat-clue-signaling). One is to, where > >> possible, negotiate the limits and use of multiple video and audio > >> subsessions as part of the CLUE Advertisment/Configure exchange, with > >> the negotiated SDP m-lines treated as an 'envelope' subdivided by > >> CLUE; this approach was the one that had more initial exploration by > >> the CLUE WG before we moved towards the SDP approach. The other > >> approach is a half-way house that has not yet been explored in any > >> detail; this is to negotiate each channel in SDP, but to express the > >> encoding constraints within the CLUE signalling. > >> > >> *** Encodings in CLUE *** > >> > >> In this approach the encodings available, and the constraints > >> associated with them, are expressed in the CLUE Advertisment. The far > >> end then selects which encodings they wish to receive, and the limits > >> on those encodings as part of the CLUE Configure message. > >> > >> In the simplest (and, most likely, commonest case) this would allow a > >> single sendrecv m-line per media type to be used for all sent and > >> received CLUE-controlled streams. The various streams must then be > >> demultiplexed; this can be done via explicit SSRC for static streams > >> or via an additional header such as appId. SSRC is used in examples; > >> replacing these with appId indicators should be roughly equivalent > >> for streams with dynamic SSRCs. As such the initial SDP, and then > >> Advertiment, might look something like: > >> > >> EXAMPLE SDP OFFER (from A) > >> m=video ... > >> ... > >> a=ssrc:1234 > >> a=ssrc:2345 > >> a=ssrc:3456 > >> a=sendrecv > >> > >> EXAMPLE ADVERTISMENT (from A) > >> Capture Scene 1: > >> Capture 1: Left (Encoding Group 1) > >> Capture 2: Center (Encoding Group 1) > >> Capture 3: Right (Encoding Group 1) > >> Capture 4: Switched > >> Capture Scene Entry 1: 1,2,3 > >> Capture Scene Entry 2: 4 > >> Simultaneous Sets: 1,2,3,4 > >> Encoding Group 1: > >> Encoding 1: H264, 1080p30, ssrc=1234 > >> Encoding 2: H264, 1080p30, ssrc=2345 > >> Encoding 3: H264, 1080p30, ssrc=3456 > >> > >> The SSRC/appId attributes are ignorable and hence sendable in the > >> initial SSRC, though implementations may prefer to leave them out > >> initially and then readvertise once CLUE is established. > >> > >> I've also included SSRCs alongside the encodings. In this case all > >> encodings are on the same m-line, but there are scenarios where this > >> multiplexing may not be appropriate or even possible, such as the > >> disaggregated case when different streams must be sent to different > >> IP addresses. In such circumstances there is a need to be able to > >> distinguish which encodings can be sent on which m-line. An > >> alternative would be to have the SSRCs only in SDP, and use something > >> else to tie that to the encodings (such as a label attribute). > >> > >> Having the encodings split across multiple m-lines will present > >> additional challenges, which will be detailed later. For now, > >> consider the rest of the simple case. The far end will complete the > >> SDP negotiation, and send a Configure message choosing what to > >> receive, something like this: > >> > >> EXAMPLE SDP ANSWER (from B) > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> > >> EXAMPLE CONFIGURATION (from B) > >> Capture 1, Encoding 1 > >> Capture 2, Encoding 2 > >> Capture 3, Encoding 3 > >> > >> At this point the sender can begin sending three media streams, which > >> the receiver can demultiplex by SSRC. > >> > >> However, one major issue remains even for the multiplexed case: how > >> to express receiver encode limitations. These are currently expressed > >> in SDP, and are defined to apply to a single media stream. However, > >> in the case above three streams are being sent to that port, and we > >> have to decide what those limits mean. > >> > >> One answer would be that it provides the *overall* limit, but this > >> quickly runs into problems. One issue is that not all parameters can > >> be sensibly subdivided: for H264 max-br and max-mbps could be divided > >> into three relatively easily, but max-fs makes less sense. And even > >> avoiding this, it would allow the far end to validly send a single > >> stream that matched the combined limit, which the receiver might not > >> be able to cope with; existing 3-screen systems often have three > >> seperate decoders that cannot pool their decode resource (eg, they > >> might be able to decode three 720p streams, but not one 1080p stream). > >> > >> As such a better answer is that the SDP receive limits express the > >> limit for *any* individual stream; in the example above each of the > >> three streams could be sent at up to 720p30. However, this still > >> poses an > >> issue: what happens if the receiver wants to receive different > >> capture encodings with different constraints. In the example above > >> most receivers will probably want all three streams at similar > >> resolutions, but in the scenario where a device wants to receive one > >> primary capture encoding to view full-screne and six > >> capture-encodings to use as small picture-in-picture insets then the > >> receiver needs to be able to express these different constraints. > >> > >> One option is for the SDP codec limit to provide a set of maxima for > >> any given stream, but then be able to express *additional* limits for > >> each capture encoding as part of the Configure message; a highly > >> simplified version might look like this: > >> > >> EXAMPLE CONFIGURATION (from B) > >> Capture 1, Encoding 1, 720p30 > >> Capture 2, Encoding 2, 360p30 > >> Capture 3, Encoding 3, 360p30 > >> > >> These would provide additional constraints on what could be sent for > >> each stream; they could only lower (not raise) the constraints > >> expressed in SDP. On the plus side, the 'encodings in CLUE' approach > >> will mean we need to create syntax to express codec-specific encoder > >> limitations for the Advertise messages, and much of that syntax could > >> use here. On the minus side, this means replicating functionality > >> that is already part of SDP. > >> > >> If we don't want to go down the route of re-expressing codec limits > >> in CLUE there is another option, which is that receivers that want to > >> express different receive limits for different capture encodings they > >> wish to receive will need to create new m-lines in the SDP so they > >> can differentiate between the capture encodings they want to receive. > >> The plus side of this approach is that this is a requirement of the > >> 'Encodings in CLUE' approach anyway, as it's needed for the case > >> where the initial answerer is a disaggregated system that doesn't > >> want to multiplex their streams; these scenarios will also need to > >> reoffer with new m-lines and split up the streams. > >> > >> The downside of this approach is that coming up with a general way to > >> mix and match multiple m-line each of which may multiplex different > >> streams, and the ability to change the the number of m-lines in use > >> and which encodings are multiplexed onto each is painful, to the > >> point where I don't have a particularly good handle on it. I've > >> included some initial speculation in an appendix at the end of the > >> page to avoid eating up too much space here. > >> > >> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': > >> * 'Encodings in SDP' approach can't express all H.264 send > >> limitations using existing SDP syntax > >> * In the straightforward multiplexed case fewer (or no) additional > >> O/As and m-lines > >> > >> Disadvantages: > >> * Need to reinvent syntax to express H264 (and any other codec) > >> limitations > >> * Problems with moving from multiplexed to non-multiplexed (and > >> similar) > >> * Media-specific information in CLUE messaging, potentially limiting > >> interoperability with other ongoing multistream work > >> > >> *** Encoding Constraints in CLUE *** > >> > >> This scenario presents a half-way house between the 'Encodings in CLUE' > >> approach expressed above and the 'Encodings in SDP' approach > >> expressed in draft-kyzivat-clue-signaling. In this case there is a > >> seperate m-line per stream, just as with the 'Encodings in SDP' > >> approach. However, in this approach the encoding constraints are > >> expressed in the CLUE Advertisment. > >> > >> Let us explore the three-screen example from before with this new > >> approach. There will be an initial SDP O/A to establish the CLUE > >> channel and verify that both sides support CLUE. There is then a new > >> SDP offer with an m-line per stream available, and a matching > advertisment: > >> > >> EXAMPLE SDP OFFER (from A) > >> m=video ... > >> ... H264@720p30 > >> a=label:A > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=label:B > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=label:C > >> a=sendrecv > >> > >> EXAMPLE ADVERTISMENT (from A) > >> Capture Scene 1: > >> Capture 1: Left (Encoding Group 1) > >> Capture 2: Center (Encoding Group 1) > >> Capture 3: Right (Encoding Group 1) > >> Capture 4: Switched > >> Capture Scene Entry 1: 1,2,3 > >> Capture Scene Entry 2: 4 > >> Simultaneous Sets: 1,2,3,4 > >> Encoding Group 1: > >> Encoding 1: H264, 1080p30, label=A > >> Encoding 2: H264, 1080p30, label=B > >> Encoding 3: H264, 1080p30, label=C > >> > >> I've used label above to tie the encodings to the m-lines, but this > >> could alternately be SSRC (if SSRC was being used), appId (if appId > >> were being used) or anything else. > >> > >> This closely matches the examples in draft-kyzivat-clue-signaling. > >> However, the sender can use 'sendrecv' rather than 'sendonly' for the > >> new m-lines rather than 'sendonly', as the encoder limits are > >> expressed instead in CLUE. This also has the advantage that the CLUE > >> syntax for these limits allows the precise H264 send limits to be > >> expressed (while SDP limits which parameters can be used in H.264 > sendonly). > >> > >> If the far end wants to receive the three static captures then it > >> sends an answer SDP which can accept those, along with a Configure > >> message specifying which captures it wants to receive: > >> > >> EXAMPLE SDP ANSWER (from B) > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> > >> EXAMPLE CONFIGURATION (from B) > >> Capture 1, Encoding 1 > >> Capture 2, Encoding 2 > >> Capture 3, Encoding 3 > >> > >> The receiver no longer needs to express the receive limits in CLUE; > >> with an m-line per received stream the standard SDP parameters > >> already allow full expression of the limitations. Now it just needs > >> to state what encoding it wants to use for each capture it receives. > >> > >> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we > >> consider the other direction (B sendings to A) then if B has three > >> streams or fewer then it will not have to make a new SDP offer. For > >> instance, if B supported up to two encodings its response could > >> instead have been: > >> > >> EXAMPLE SDP ANSWER (from B) > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=sendrecv > >> m=video ... > >> ... H264@720p30 > >> a=recvonly > >> > >> And could immediately send an Advertisment with its capture and > >> encoding information. A new offer would be needed if B had more > >> encodings than A, or if A wanted to change its receive capabilities > >> based on the capture encodings it wanted from A. > >> > >> This approach is very like the 'Encodings in SDP' approach, with the > >> following advantages and disadvantages: > >> > >> Advantages relative to 'Encodings in SDP': > >> * 'Encodings in SDP' approach can't express all H.264 send > >> limitations using existing SDP syntax > >> * Many m-lines can be sendrecv, in many cases will need fewer O/As > >> > >> Disadvantages: > >> * Still need to reinvent syntax to express H264 (and any other codec) > >> encoding limitations > >> > >> *** Summary *** > >> > >> Appealing as the 'Encodings in CLUE' case is when all streams of a > >> given media type can be multiplexed onto a single m-line, treating > >> SDP as an 'envelope' CLUe can subdivide, I don't believe this > >> approach is actually feasible. Also having to support the multiple > >> m-line case and be able to sensibly change the number of m-lines is > >> painful, while the need to replicate receive codec limits in CLUE > >> that are already expressed very capably in SDP is unlikely to be popular. > >> > >> I believe the 'Encoding *constraints* in CLUE' approach is > >> considerably more plausible, though the variation from the 'Encodings in > SDP' > >> approach is fairly small. Principly it comes down to whether the work > >> required to develop syntax to express the send limits for the various > >> codecs in CLUE is worth the added accuracy of what can be expressed > >> in CLUE over what is currently available in SDP, along with the > >> advantage of less need to add new m-lines (and the associated O/As > involved). > >> > >> *** Appendix *** > >> > >> Let us first consider the case of wanting to split an offered set of > >> streams. The sender (A) can send up to five capture encodings, and so > >> send an SDP offer along the lines of: > >> > >> m=video ... > >> ... > >> a=ssrc:1234 > >> a=ssrc:2345 > >> a=ssrc:3456 > >> a=ssrc:4567 > >> a=ssrc:5678 > >> a=sendrecv > >> > >> The receiver (B) wants to receive one of those streams on one m-line, > >> three more on a second m-line and the fifth not at all. The rules of > >> O/A mean that B must send an initial answer with the single m-line, > >> which we won't illustrate here, and then send a new offer. Some > >> method must be provided to show what streams are to be received > >> where; in this case I'm using the max-ssrc draft: > >> > >> m=video ... > >> ... > >> a=max-recv-ssrc:{*:1} > >> a=sendrecv > >> m=video ... > >> ... > >> a=max-recv-ssrc:{*:3} > >> a=sendrecv > >> m=video ... 0 > >> > >> A will then need to reorder their allocation of SSRCs to m-lines to > >> sensibly fit this. And if later in the call B decides that it now > >> wants to multiplex all of the streams this will need to be done in > >> reverse, with B sending a new offer with only one activevideo m-line > >> and suitable max-recv-ssrc value and hope that A will correctly > >> interpret this. This reallocation of streams between m-lines is the > >> part I think will be difficult to define normatively. > >> > >> Rob > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Oct 9 12:25:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65FD21E8196 for ; Wed, 9 Oct 2013 12:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.647 X-Spam-Level: X-Spam-Status: No, score=0.647 tagged_above=-999 required=5 tests=[AWL=-0.716, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdNXWxHc7RtH for ; Wed, 9 Oct 2013 12:24:58 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 9E87B21E8190 for ; Wed, 9 Oct 2013 12:24:34 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id azAG1m0031GhbT85F7QYYf; Wed, 09 Oct 2013 19:24:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id b7QX1m00w3ZTu2S3T7QYHk; Wed, 09 Oct 2013 19:24:32 +0000 Message-ID: <5255AD6F.8070302@alum.mit.edu> Date: Wed, 09 Oct 2013 15:24:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roni Even References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> <525578E9.6010500@alum.mit.edu> <009901cec511$73984d00$5ac8e700$@gmail.com> In-Reply-To: <009901cec511$73984d00$5ac8e700$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381346672; bh=908EcmjiXGY6/u303Io19TsQtzNw1sHjUgUW79zI7dg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DdHl1G08fMl+XI+d1rYAGMBETfKw/1ZPRy5nDNexxkYp5IJzM82Q6/dcG9J3VVPSx zQuo5b8emQvQXAjgiRQTh7Gh0vD1sTXBZKeOZZV0cRmNMYWqFY5EYMxhYK5PXW9M+4 JevZxVMR+gYE8pHq5sYTNN/YIiARagks5pgnRcp0amZawuaz+8Z165nzJFxDmp0rYo l2rG5d7LIFTr7Th3CIv82y/zGTtCK3FYMiy7vmQwdz9Hp5/4e1MrIZTDZN0FnArdwo 5VUkYstQx0Cm3pGUN3JiY6lQ9ouCIfQKpOUKUPxUrGvnmBnVFJy5rpayOR84vhUWUR eeTSrZeQQuX+Q== Cc: clue@ietf.org Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:25:09 -0000 On 10/9/13 1:03 PM, Roni Even wrote: > Hi, > Some quick points, I still need to look more into the options and I was busy > this week and could not attend the Tuesday call. > > As for Paul concern about the resource allocation when providing the > encoding is SDP , I think that this is not an issue since the m-lines > specify sendonly streams to be used by the advertisement (section 6 examples > of the signaling draft) My understanding of how when/how the bandwidth is managed is pretty fuzzy. But it would be nice if it isn't a problem in this case. Reserving ports, ICE, etc. is still an issue, but bundle will help with that. Thanks, Paul > My general view on the encoding was not favorable from the start. I could > not understand why we need the resource management as part of CLUE. My past > experience was that trying to optimize resource per each codec is not easy > and it is better to use abstract compute units that are codec independent > but allow for multiplications of the unit based on capabilities. For example > H.264 CIF will be one unit and H.264 HD will use 4 units and VP8 HD will use > 4 units (not real numbers just an example), still I am not sure why in CLUE > where we wanted to address relations between streams (spatial) we invest so > much in resource management. > > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: 09 October, 2013 6:40 PM >> To: clue@ietf.org >> Subject: Re: [clue] Expressing encoding information in CLUE >> >> Rob, >> >> Thanks for digging into this and getting the discussion started. >> This is an important decision, so we need some vigorous discussion. I'm >> looking for feedback from everybody that is actively involved in this. >> >> I've been on both sides of this. I've pursued the encoding-in-SDP approach > in >> the signaling document. In part because of the consequences that showed >> up in doing that I've been pushing the exploration of the alternative(s). > Now >> we have that. >> >> With the encoding-in-SDP approach I remain disturbed by the need for the >> advertiser to commit media resources (ports, bandwidth) for all the >> encodings it wants to mention in an advertisement. I think this could be > quite >> burdensome, especially for an MCU, that may be advertising many more >> options than any one endpoint is likely to use. This will be less of a > problem >> with bundling, but it still may be a burden wrt bandwidth commitments. It >> would be unfortunate if the MCU must limit itself in the number of >> encodings it offers to avoid the call being blocked for demanding too much >> bandwidth. >> >> OTOH, I appreciate Rob's concern over reinventing syntax for codec > specific >> constraints. >> >> There is no perfect answer here - we must pick our poison. >> >> I'm not going to make a choice of my own now (maybe ever). I want to see >> what others say. >> >> Thanks, >> Paul >> >> On 10/8/13 2:15 PM, Robert Hansen wrote: >>> The previous was an attempt at a relatively objective look at the >>> different syntactic options for conveying encoding information in CLUE. >>> However, I do have opinions on the options available. >>> >>> The proposal for negotiating both encodings and multiplexing behaviour >>> in CLUE was included because it's something we have discussed heavily >>> in the past. However there were good reason we moved away from it - it >>> provides a CLUE-specific method of multiplexing that won't play well >>> with the syntax being defined in the wider MMUSIC sphere, as well as >>> all the problems inhereit with multiplexing on a single m-line. >>> >>> The other two options explored use SDP for multiplexing, but one >>> expressed the encoding limitations in SDP while the other does so in >>> CLUE. I think both are workable solutions, but my preference is for >>> the SDP option. >>> >>> While the expressing encoding limitations in CLUE approach does >>> provide a number of advantages: fewer m-lines, fewer O/As, more >>> accurate encoder limitations and (as Paul pointed out in the design >>> call today) the ability to express encoder limitations without >>> committing resources, I think the need to come up with syntax for the >>> encoding limits in CLUE is a painful one. If these limits can be >>> expressed in abstract, codec-independent ways then that's one thing, >>> but each time this issue comes up somewhere the upshot seems to be >>> that abstract, codec-independent limitations aren't actually possible, >>> and that would leave us with the need to reinvent syntax for any codec >> that could be used. >>> >>> I'd be very happy to be proved wrong about this, but I don't think the >>> advantages of expressing the encoding constraints in CLUE are >>> sufficient to outweight the cost of such codec-specific work, and I >>> don't think we'll be able to come up with a nice abstraction everyone > will >> sign off on. >>> >>> Rob >>> >>> On 08/10/2013 09:35, Robert Hansen wrote: >>>> At the design meeting last week I volunteered to take a stab at >>>> evaluating alternate approaches to conveying all encoding information >>>> in SDP. The text got a bit long for an email, so I've also attached >>>> it as a text document. I'll also put together some slides on the >>>> topic for this call this afternoon. >>>> >>>> One of the fundamental issues we have in clue is how to negotiate the >>>> details of the encodings defined in draft-ietf-clue-framework. Unless >>>> other entities such as captures, which are unique to CLUE, encodings >>>> share many properties with limits that are currently expressible in >>>> SDP, but have additional requirements and limits that are less good >>>> fits for SDP. One of the >>>> >>>> The current assumption we have been working from, as detailed in >>>> draft-kyzivat-clue-signaling, is that the encodings (defined in >>>> draft-ietf-clue-framework), will be expressed in SDP and not in the >>>> CLUE signalling. However, this has only ever been a working >>>> assumption rather than something we've reached consensus on, and this >>>> is a fundamental design decision that impacts not just the message >>>> syntax but also the call flows and state machines inherent in the >>>> signalling. As such, I volunteered to examine the alternative >>>> approach, to hopefully allow us to resolve this issue so we can move >> forward. >>>> >>>> To do this I am going to examine two alternate options (for deails of >>>> the SDP approach see draft-kyzivat-clue-signaling). One is to, where >>>> possible, negotiate the limits and use of multiple video and audio >>>> subsessions as part of the CLUE Advertisment/Configure exchange, with >>>> the negotiated SDP m-lines treated as an 'envelope' subdivided by >>>> CLUE; this approach was the one that had more initial exploration by >>>> the CLUE WG before we moved towards the SDP approach. The other >>>> approach is a half-way house that has not yet been explored in any >>>> detail; this is to negotiate each channel in SDP, but to express the >>>> encoding constraints within the CLUE signalling. >>>> >>>> *** Encodings in CLUE *** >>>> >>>> In this approach the encodings available, and the constraints >>>> associated with them, are expressed in the CLUE Advertisment. The far >>>> end then selects which encodings they wish to receive, and the limits >>>> on those encodings as part of the CLUE Configure message. >>>> >>>> In the simplest (and, most likely, commonest case) this would allow a >>>> single sendrecv m-line per media type to be used for all sent and >>>> received CLUE-controlled streams. The various streams must then be >>>> demultiplexed; this can be done via explicit SSRC for static streams >>>> or via an additional header such as appId. SSRC is used in examples; >>>> replacing these with appId indicators should be roughly equivalent >>>> for streams with dynamic SSRCs. As such the initial SDP, and then >>>> Advertiment, might look something like: >>>> >>>> EXAMPLE SDP OFFER (from A) >>>> m=video ... >>>> ... >>>> a=ssrc:1234 >>>> a=ssrc:2345 >>>> a=ssrc:3456 >>>> a=sendrecv >>>> >>>> EXAMPLE ADVERTISMENT (from A) >>>> Capture Scene 1: >>>> Capture 1: Left (Encoding Group 1) >>>> Capture 2: Center (Encoding Group 1) >>>> Capture 3: Right (Encoding Group 1) >>>> Capture 4: Switched >>>> Capture Scene Entry 1: 1,2,3 >>>> Capture Scene Entry 2: 4 >>>> Simultaneous Sets: 1,2,3,4 >>>> Encoding Group 1: >>>> Encoding 1: H264, 1080p30, ssrc=1234 >>>> Encoding 2: H264, 1080p30, ssrc=2345 >>>> Encoding 3: H264, 1080p30, ssrc=3456 >>>> >>>> The SSRC/appId attributes are ignorable and hence sendable in the >>>> initial SSRC, though implementations may prefer to leave them out >>>> initially and then readvertise once CLUE is established. >>>> >>>> I've also included SSRCs alongside the encodings. In this case all >>>> encodings are on the same m-line, but there are scenarios where this >>>> multiplexing may not be appropriate or even possible, such as the >>>> disaggregated case when different streams must be sent to different >>>> IP addresses. In such circumstances there is a need to be able to >>>> distinguish which encodings can be sent on which m-line. An >>>> alternative would be to have the SSRCs only in SDP, and use something >>>> else to tie that to the encodings (such as a label attribute). >>>> >>>> Having the encodings split across multiple m-lines will present >>>> additional challenges, which will be detailed later. For now, >>>> consider the rest of the simple case. The far end will complete the >>>> SDP negotiation, and send a Configure message choosing what to >>>> receive, something like this: >>>> >>>> EXAMPLE SDP ANSWER (from B) >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> >>>> EXAMPLE CONFIGURATION (from B) >>>> Capture 1, Encoding 1 >>>> Capture 2, Encoding 2 >>>> Capture 3, Encoding 3 >>>> >>>> At this point the sender can begin sending three media streams, which >>>> the receiver can demultiplex by SSRC. >>>> >>>> However, one major issue remains even for the multiplexed case: how >>>> to express receiver encode limitations. These are currently expressed >>>> in SDP, and are defined to apply to a single media stream. However, >>>> in the case above three streams are being sent to that port, and we >>>> have to decide what those limits mean. >>>> >>>> One answer would be that it provides the *overall* limit, but this >>>> quickly runs into problems. One issue is that not all parameters can >>>> be sensibly subdivided: for H264 max-br and max-mbps could be divided >>>> into three relatively easily, but max-fs makes less sense. And even >>>> avoiding this, it would allow the far end to validly send a single >>>> stream that matched the combined limit, which the receiver might not >>>> be able to cope with; existing 3-screen systems often have three >>>> seperate decoders that cannot pool their decode resource (eg, they >>>> might be able to decode three 720p streams, but not one 1080p stream). >>>> >>>> As such a better answer is that the SDP receive limits express the >>>> limit for *any* individual stream; in the example above each of the >>>> three streams could be sent at up to 720p30. However, this still >>>> poses an >>>> issue: what happens if the receiver wants to receive different >>>> capture encodings with different constraints. In the example above >>>> most receivers will probably want all three streams at similar >>>> resolutions, but in the scenario where a device wants to receive one >>>> primary capture encoding to view full-screne and six >>>> capture-encodings to use as small picture-in-picture insets then the >>>> receiver needs to be able to express these different constraints. >>>> >>>> One option is for the SDP codec limit to provide a set of maxima for >>>> any given stream, but then be able to express *additional* limits for >>>> each capture encoding as part of the Configure message; a highly >>>> simplified version might look like this: >>>> >>>> EXAMPLE CONFIGURATION (from B) >>>> Capture 1, Encoding 1, 720p30 >>>> Capture 2, Encoding 2, 360p30 >>>> Capture 3, Encoding 3, 360p30 >>>> >>>> These would provide additional constraints on what could be sent for >>>> each stream; they could only lower (not raise) the constraints >>>> expressed in SDP. On the plus side, the 'encodings in CLUE' approach >>>> will mean we need to create syntax to express codec-specific encoder >>>> limitations for the Advertise messages, and much of that syntax could >>>> use here. On the minus side, this means replicating functionality >>>> that is already part of SDP. >>>> >>>> If we don't want to go down the route of re-expressing codec limits >>>> in CLUE there is another option, which is that receivers that want to >>>> express different receive limits for different capture encodings they >>>> wish to receive will need to create new m-lines in the SDP so they >>>> can differentiate between the capture encodings they want to receive. >>>> The plus side of this approach is that this is a requirement of the >>>> 'Encodings in CLUE' approach anyway, as it's needed for the case >>>> where the initial answerer is a disaggregated system that doesn't >>>> want to multiplex their streams; these scenarios will also need to >>>> reoffer with new m-lines and split up the streams. >>>> >>>> The downside of this approach is that coming up with a general way to >>>> mix and match multiple m-line each of which may multiplex different >>>> streams, and the ability to change the the number of m-lines in use >>>> and which encodings are multiplexed onto each is painful, to the >>>> point where I don't have a particularly good handle on it. I've >>>> included some initial speculation in an appendix at the end of the >>>> page to avoid eating up too much space here. >>>> >>>> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': >>>> * 'Encodings in SDP' approach can't express all H.264 send >>>> limitations using existing SDP syntax >>>> * In the straightforward multiplexed case fewer (or no) additional >>>> O/As and m-lines >>>> >>>> Disadvantages: >>>> * Need to reinvent syntax to express H264 (and any other codec) >>>> limitations >>>> * Problems with moving from multiplexed to non-multiplexed (and >>>> similar) >>>> * Media-specific information in CLUE messaging, potentially limiting >>>> interoperability with other ongoing multistream work >>>> >>>> *** Encoding Constraints in CLUE *** >>>> >>>> This scenario presents a half-way house between the 'Encodings in CLUE' >>>> approach expressed above and the 'Encodings in SDP' approach >>>> expressed in draft-kyzivat-clue-signaling. In this case there is a >>>> seperate m-line per stream, just as with the 'Encodings in SDP' >>>> approach. However, in this approach the encoding constraints are >>>> expressed in the CLUE Advertisment. >>>> >>>> Let us explore the three-screen example from before with this new >>>> approach. There will be an initial SDP O/A to establish the CLUE >>>> channel and verify that both sides support CLUE. There is then a new >>>> SDP offer with an m-line per stream available, and a matching >> advertisment: >>>> >>>> EXAMPLE SDP OFFER (from A) >>>> m=video ... >>>> ... H264@720p30 >>>> a=label:A >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=label:B >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=label:C >>>> a=sendrecv >>>> >>>> EXAMPLE ADVERTISMENT (from A) >>>> Capture Scene 1: >>>> Capture 1: Left (Encoding Group 1) >>>> Capture 2: Center (Encoding Group 1) >>>> Capture 3: Right (Encoding Group 1) >>>> Capture 4: Switched >>>> Capture Scene Entry 1: 1,2,3 >>>> Capture Scene Entry 2: 4 >>>> Simultaneous Sets: 1,2,3,4 >>>> Encoding Group 1: >>>> Encoding 1: H264, 1080p30, label=A >>>> Encoding 2: H264, 1080p30, label=B >>>> Encoding 3: H264, 1080p30, label=C >>>> >>>> I've used label above to tie the encodings to the m-lines, but this >>>> could alternately be SSRC (if SSRC was being used), appId (if appId >>>> were being used) or anything else. >>>> >>>> This closely matches the examples in draft-kyzivat-clue-signaling. >>>> However, the sender can use 'sendrecv' rather than 'sendonly' for the >>>> new m-lines rather than 'sendonly', as the encoder limits are >>>> expressed instead in CLUE. This also has the advantage that the CLUE >>>> syntax for these limits allows the precise H264 send limits to be >>>> expressed (while SDP limits which parameters can be used in H.264 >> sendonly). >>>> >>>> If the far end wants to receive the three static captures then it >>>> sends an answer SDP which can accept those, along with a Configure >>>> message specifying which captures it wants to receive: >>>> >>>> EXAMPLE SDP ANSWER (from B) >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> >>>> EXAMPLE CONFIGURATION (from B) >>>> Capture 1, Encoding 1 >>>> Capture 2, Encoding 2 >>>> Capture 3, Encoding 3 >>>> >>>> The receiver no longer needs to express the receive limits in CLUE; >>>> with an m-line per received stream the standard SDP parameters >>>> already allow full expression of the limitations. Now it just needs >>>> to state what encoding it wants to use for each capture it receives. >>>> >>>> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we >>>> consider the other direction (B sendings to A) then if B has three >>>> streams or fewer then it will not have to make a new SDP offer. For >>>> instance, if B supported up to two encodings its response could >>>> instead have been: >>>> >>>> EXAMPLE SDP ANSWER (from B) >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=sendrecv >>>> m=video ... >>>> ... H264@720p30 >>>> a=recvonly >>>> >>>> And could immediately send an Advertisment with its capture and >>>> encoding information. A new offer would be needed if B had more >>>> encodings than A, or if A wanted to change its receive capabilities >>>> based on the capture encodings it wanted from A. >>>> >>>> This approach is very like the 'Encodings in SDP' approach, with the >>>> following advantages and disadvantages: >>>> >>>> Advantages relative to 'Encodings in SDP': >>>> * 'Encodings in SDP' approach can't express all H.264 send >>>> limitations using existing SDP syntax >>>> * Many m-lines can be sendrecv, in many cases will need fewer O/As >>>> >>>> Disadvantages: >>>> * Still need to reinvent syntax to express H264 (and any other codec) >>>> encoding limitations >>>> >>>> *** Summary *** >>>> >>>> Appealing as the 'Encodings in CLUE' case is when all streams of a >>>> given media type can be multiplexed onto a single m-line, treating >>>> SDP as an 'envelope' CLUe can subdivide, I don't believe this >>>> approach is actually feasible. Also having to support the multiple >>>> m-line case and be able to sensibly change the number of m-lines is >>>> painful, while the need to replicate receive codec limits in CLUE >>>> that are already expressed very capably in SDP is unlikely to be > popular. >>>> >>>> I believe the 'Encoding *constraints* in CLUE' approach is >>>> considerably more plausible, though the variation from the 'Encodings > in >> SDP' >>>> approach is fairly small. Principly it comes down to whether the work >>>> required to develop syntax to express the send limits for the various >>>> codecs in CLUE is worth the added accuracy of what can be expressed >>>> in CLUE over what is currently available in SDP, along with the >>>> advantage of less need to add new m-lines (and the associated O/As >> involved). >>>> >>>> *** Appendix *** >>>> >>>> Let us first consider the case of wanting to split an offered set of >>>> streams. The sender (A) can send up to five capture encodings, and so >>>> send an SDP offer along the lines of: >>>> >>>> m=video ... >>>> ... >>>> a=ssrc:1234 >>>> a=ssrc:2345 >>>> a=ssrc:3456 >>>> a=ssrc:4567 >>>> a=ssrc:5678 >>>> a=sendrecv >>>> >>>> The receiver (B) wants to receive one of those streams on one m-line, >>>> three more on a second m-line and the fifth not at all. The rules of >>>> O/A mean that B must send an initial answer with the single m-line, >>>> which we won't illustrate here, and then send a new offer. Some >>>> method must be provided to show what streams are to be received >>>> where; in this case I'm using the max-ssrc draft: >>>> >>>> m=video ... >>>> ... >>>> a=max-recv-ssrc:{*:1} >>>> a=sendrecv >>>> m=video ... >>>> ... >>>> a=max-recv-ssrc:{*:3} >>>> a=sendrecv >>>> m=video ... 0 >>>> >>>> A will then need to reorder their allocation of SSRCs to m-lines to >>>> sensibly fit this. And if later in the call B decides that it now >>>> wants to multiplex all of the streams this will need to be done in >>>> reverse, with B sending a new offer with only one activevideo m-line >>>> and suitable max-recv-ssrc value and hope that A will correctly >>>> interpret this. This reallocation of streams between m-lines is the >>>> part I think will be difficult to define normatively. >>>> >>>> Rob >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From pkyzivat@alum.mit.edu Wed Oct 9 12:48:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F821E81A5 for ; Wed, 9 Oct 2013 12:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.217 X-Spam-Level: X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2CedSxWGG4b for ; Wed, 9 Oct 2013 12:48:16 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 908C421E8191 for ; Wed, 9 Oct 2013 12:48:07 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta15.westchester.pa.mail.comcast.net with comcast id b6kH1m0071GhbT85F7o6Tz; Wed, 09 Oct 2013 19:48:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id b7o61m00M3ZTu2S3T7o6Su; Wed, 09 Oct 2013 19:48:06 +0000 Message-ID: <5255B2F5.1050200@alum.mit.edu> Date: Wed, 09 Oct 2013 15:48:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> In-Reply-To: <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381348086; bh=wfBDymrt7aoRlMn0tzxGxa2cCK0wXOvdcdiV+KziKKk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LJ9+PoIWJHBz3NAXjzQLk4bFQvUPMEZv2t5l5YAkKHwD+kx+40gN039q5p6WaTjXm GQLT4zXIdtafIruiOAHkzNw1y3qI8/0JAYIg/PI/g01f0UCVngzYIT9RgeMrffM2RF Enu3bonOljZ1nt6VYfvGJzI1A/IDEWLHvWpko6rjKDfbLG79IuMZ4yFrS6/oxCEoBy /HWGzhNhC1bXvsT/aNFz1NpZ7bN3r1nMKd6ARAKnxV4IsjTZPdhBgCmWU7J0UnarLv LQqXxxIQXyCqPnEFWUH3vdHpN74RvZyok04eDx7tykrxEM3VckQH4BvNCwJA11m2e8 szkYmQL+WrKPw== Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 19:48:37 -0000 Roberta, Thanks for this update. Its good to see progress. Would you be willing to discuss it in the design team meeting next week? A few comments... Section 3: This describes this as a client-server protocol, with the MC being the client and the MP being the server. But in reality we are usually in the situation where both ends have both an MC and MP role. And their messages are mixed on the same channel. I think it is necessary to address this as a single peer-to-peer protocol containing one or two nested client-server sub-protocols. The p2p protocol can be just a mux/demux that sorts messages into one or the other of the sub-protocols. (I guess the rule is that ADV and RESPONSE are sent to the MC state machine, while RESPONSE, RE-ADV and OPTIONS are sent to the MP state machine.) And presumably channel failures, and ill-formed messages that can't be sorted to one of the sub-protocols need to be dealt with at this level. (And then they may affect the state of the sub-protocols.) Alternatively, we *could* consider using two channels, each one being client-server. Section 5: What causes an MC to come into existence? Does every clue endpoint have one? Or is it optional. (E.g., a provider-only device.) Conversely, is it an error to not get an Advertisement? Couldn't there be consumer-only devices? Its certainly possible to make the protocol work with these being optional or required. But the details are different, so we need to choose. The message has to be parsed (at least in part) in order to determine that it is an advertisement. ISTM most parse errors will occur then. So I think they show up in the missing state machine I talk about above re Section 3. I suppose there may be some (probably semantic) errors that are detected after knowing the message is an advertisement. Handling those would belong in this state machine. I see that a CONF is required in response to an ADV. Is it your intent that this is to be sent soon (less than human response time)? Or is it your expectation that it is ok for this to be delayed long enough to allow human interaction and choice? (Which could be several minutes, or more.) I think this is an important distinction to make clear. Thanks, Paul From Christian.Groves@nteczone.com Wed Oct 9 22:16:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3B21F9CB5 for ; Wed, 9 Oct 2013 22:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAG3Hp-KMLik for ; Wed, 9 Oct 2013 22:16:17 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 4129521F9CAF for ; Wed, 9 Oct 2013 22:16:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAI3VlJ20WhU/2dsb2JhbAANTcUqgTSDGQEBAQQ4GxUQEQsSBgkWCAcJAwIBAgE0Aw4TBgIBARetf5Mtj0wWhA0DlCaZFg Received: from ppp118-209-104-84.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.104.84]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Oct 2013 15:46:15 +1030 Message-ID: <52563818.8040402@nteczone.com> Date: Thu, 10 Oct 2013 16:16:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <52403F44.2060609@unina.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 05:16:18 -0000 Hello, Please see my comments below. Regards, Christian On 9/10/2013 10:03 PM, Mary Barnes wrote: > Hi Roberta, > > Thank you for your review comments. I apologize for the delay in > responding. I've been traveling for the past 3+ weeks and seem to be > processing my emails LIFO. > > My responses are below [MB]. > > Thanks, > Mary. > > > On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta > > wrote: > > Hi all, > > in the following some comments to the requirements draft. > > * about the interworking telepresence systems > In the Introduction section (page 3, third paragraph), it is > stated that the purpose of the document is to provide > requirements for enabling interworking between /"SIP-based > [RFC3261] telepresence systems"/. We should describe/define > here in a more precise way these systems, by saying for > example that they are "built upon" centralized SIP-based > conferencing systems as defined in RFC4353 (the "conference" > definition in the following refers to this RFC). We should > explicitely mention that we are not dealing with "signaling > agnostic" frameworks, if this is the case, i.e. if we leverage > SIP as the only signaling protocol for the basic session > management. > > [MB] Good point. How about something like the following change: > OLD: > The purpose of this document is to describe the requirements for a > specification that enables interworking between different SIP-based > [RFC3261] telepresence systems, by exchanging and negotiating > appropriate information. > > NEW: > The purpose of this document is to describe the requirements for a > specification that enables interworking between different SIP-based > [RFC3261] telepresence systems by exchanging and negotiating > appropriate information. In the context of these requirements and > related > solutions, the SIP telepresence systems are expected to support the > SIP conferencing > framework [RFC 4353] and SIP based conference control [RFC 4579] . [CNG] I don't agree that it is expected that telepresence systems support RFC4353 and 4579. CLUE should be able to be used without these. Especially in the case of point to point CLUE calls. The use of RFC4353 and RFC4579 shouldn't be precluded however. > > * about dictating architectural choices > In the Introduction section, "/It is not the intention of CLUE > to dictate telepresence architectural and implementation > choices./" I would propose to erase "architectural choice" and > to leave only "implementation choice". The CLUE framework > should provide some reference architecture for SIP-based > telepresence systems in order to let them interoperate, so I > would not say that CLUE is not intended to dictate > architectural choice. > > [MB] I agree. [/MB] [CNG] I would prefer to leave the existing text. I believe that was the original intention. ..snip.. From roberta.presta@unina.it Thu Oct 10 04:04:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1221E80EE for ; Thu, 10 Oct 2013 04:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRFXFfHdj7ZE for ; Thu, 10 Oct 2013 04:03:55 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 280C021E809E for ; Thu, 10 Oct 2013 04:03:54 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.163]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r9AB3oZv017131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Oct 2013 13:03:51 +0200 Message-ID: <52568997.9070308@unina.it> Date: Thu, 10 Oct 2013 13:03:51 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> <5255B2F5.1050200@alum.mit.edu> In-Reply-To: <5255B2F5.1050200@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 131009-1, 09/10/2013), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 11:04:00 -0000 Hi Paul, I will prepare some slides for the next design team meeting to discuss the updates to the protocol draft. Please see inline for further comments. Il 09/10/2013 21:48, Paul Kyzivat ha scritto: > > Section 3: > > This describes this as a client-server protocol, with the MC being the > client and the MP being the server. But in reality we are usually in > the situation where both ends have both an MC and MP role. And their > messages are mixed on the same channel. I think it is necessary to > address this as a single peer-to-peer protocol containing one or two > nested client-server sub-protocols. > > The p2p protocol can be just a mux/demux that sorts messages into one > or the other of the sub-protocols. (I guess the rule is that ADV and > RESPONSE are sent to the MC state machine, while RESPONSE, RE-ADV and > OPTIONS are sent to the MP state machine.) The demux rule should be: - from the MC to the MP: OPTIONS, CONFIGURE, READV (only requests) - from the MP to the MC: ADV, RESPONSE (only notifications and responses) We have not considered yet the ack/nack mechanism needed to address the DTLS/SCTP channel issues. > And presumably channel failures, and ill-formed messages that can't be > sorted to one of the sub-protocols need to be dealt with at this > level. (And then they may affect the state of the sub-protocols.) > > Alternatively, we *could* consider using two channels, each one being > client-server. > > Section 5: > > What causes an MC to come into existence? Does every clue endpoint > have one? Or is it optional. (E.g., a provider-only device.) > > Conversely, is it an error to not get an Advertisement? Couldn't there > be consumer-only devices? > > Its certainly possible to make the protocol work with these being > optional or required. But the details are different, so we need to > choose. I see your point. A CLUE endpoint can surely be also provider-only or consumer-only. We have considered that the peer-to-peer CLUE channel is created between at least an MC and an MP (since, otherwise, it is useless to set up it). However, that presupposes that during the channel set up phase it is possible to understand when the involved parties are both consumer-(or provider-) only, and in that cases the channel should not be created. If we remove that hypotesis that can lead us in trouble, we have still a way out with the current draft. Indeed, when the channel is ready, it is the MC side that starts the CLUE dialogue with an OPTIONS request to align with the MP about the version and the extensions to be used within the session. If both parties are provider-only, the current (only) way to detect that condition is that the channel is inactive for a time that fires N timeouts of the MP machine (no OPTIONS received). On the other hand, the current (only) way to detect that both peers are consumer-only is that there is no answer to the OPTIONS request. But alternatives can be considered. > The message has to be parsed (at least in part) in order to determine > that it is an advertisement. ISTM most parse errors will occur then. > So I think they show up in the missing state machine I talk about > above re Section 3. I suppose there may be some (probably semantic) > errors that are detected after knowing the message is an > advertisement. Handling those would belong in this state machine. > > I see that a CONF is required in response to an ADV. Is it your intent > that this is to be sent soon (less than human response time)? Or is it > your expectation that it is ok for this to be delayed long enough to > allow human interaction and choice? (Which could be several minutes, > or more.) I think this is an important distinction to make clear. > The CONF request, in the form depicted in the protocol draft, is not conceived as a response to the ADV. It is a request of configuration that can be sent only after an ADVERTISEMENT has been received. However, after a first ADV has been received, a CONF request can be issued also without receiving a new ADV if, for example, the MC wants to change the something in the current configuration. Actually, we have not made any hypotesis about when issuing a CONF. We rather assume that the CONF is simply issued when it is ready, i.e. when the ADV has been parsed and interpreted and the desired streams have been "translated" in the CONF message. That can happen after an automatic elaboration, for example according to some policy of the receiver, or after a human configuration, it the MC party has some software designed to enable a human selection of the desired features. Thank you, Roberta > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Oct 10 04:10:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F2121E8115 for ; Thu, 10 Oct 2013 04:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.602 X-Spam-Level: X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVaowD8T7+kp for ; Thu, 10 Oct 2013 04:10:47 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AC8B621E8116 for ; Thu, 10 Oct 2013 04:10:38 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id w8so398634qac.1 for ; Thu, 10 Oct 2013 04:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2bcYyYySgarz38RMurcnhrfhivPG7B85OxPoheWJ8sw=; b=bInsvhlSfGPsY3ly+DMFcFn2cHKpQURSyZoelZ3Ti2rlcaoZUJdoSGrHXQU9bT1t9G oFhNW3pxsFvDfvQTWsbkDBVPSUAYCHwAMfk2iogjIPIfRFrnxOMN07ykY7R9Jp88Ks1y dXm/xlH7WegeWYf1x/QFjK/uqoqs5GALxiVwkV15R5Gd22Xh+wKiC4pU9fMAuNoBdbkG qTI0mCbDuCmpJVSeyYC6a+zYONXKLxLJyj5jKB9pVaJgWuOGyerfqixTNIWFNOAgy1uZ KLxUa8G4gbmBFA7uz/rs6+Mm5uFjSi14esF1LP7s4PcbXo3Pli1NgKuNxo/Xusn+ORSw XVrQ== MIME-Version: 1.0 X-Received: by 10.49.59.115 with SMTP id y19mr13682932qeq.8.1381403438106; Thu, 10 Oct 2013 04:10:38 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 10 Oct 2013 04:10:38 -0700 (PDT) In-Reply-To: <52563818.8040402@nteczone.com> References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> Date: Thu, 10 Oct 2013 06:10:38 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b6221ea38692f04e8610d48 Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 11:10:48 -0000 --047d7b6221ea38692f04e8610d48 Content-Type: text/plain; charset=ISO-8859-1 My responses below [MB2]. Mary On Thu, Oct 10, 2013 at 12:16 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > Please see my comments below. > > Regards, Christian > > > On 9/10/2013 10:03 PM, Mary Barnes wrote: > >> Hi Roberta, >> >> Thank you for your review comments. I apologize for the delay in >> responding. I've been traveling for the past 3+ weeks and seem to be >> processing my emails LIFO. >> >> My responses are below [MB]. >> >> Thanks, >> Mary. >> >> >> On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta > roberta.presta@unina.**it >> wrote: >> >> Hi all, >> >> in the following some comments to the requirements draft. >> >> * about the interworking telepresence systems >> >> In the Introduction section (page 3, third paragraph), it is >> stated that the purpose of the document is to provide >> requirements for enabling interworking between /"SIP-based >> [RFC3261] telepresence systems"/. We should describe/define >> >> here in a more precise way these systems, by saying for >> example that they are "built upon" centralized SIP-based >> conferencing systems as defined in RFC4353 (the "conference" >> definition in the following refers to this RFC). We should >> explicitely mention that we are not dealing with "signaling >> agnostic" frameworks, if this is the case, i.e. if we leverage >> SIP as the only signaling protocol for the basic session >> management. >> >> [MB] Good point. How about something like the following change: >> OLD: >> The purpose of this document is to describe the requirements for a >> specification that enables interworking between different SIP-based >> [RFC3261] telepresence systems, by exchanging and negotiating >> appropriate information. >> >> NEW: >> The purpose of this document is to describe the requirements for a >> specification that enables interworking between different SIP-based >> [RFC3261] telepresence systems by exchanging and negotiating >> appropriate information. In the context of these requirements and >> related >> solutions, the SIP telepresence systems are expected to support the >> SIP conferencing >> framework [RFC 4353] and SIP based conference control [RFC 4579] . >> > > [CNG] I don't agree that it is expected that telepresence systems support > RFC4353 and 4579. CLUE should be able to be used without these. Especially > in the case of point to point CLUE calls. The use of RFC4353 and RFC4579 > shouldn't be precluded however. > [MB2] I would agree for a point to point, so we adjust the wording to accommodate that. However, our WG is explicitly chartered to be based on SIP Conferencing. Text from the charter: " WG will create specifications for SIP-based conferencing systems" I would suggest the following new text to be explicit about point to point. NEW: The purpose of this document is to describe the requirements for a specification that enables interworking between different SIP-based [RFC3261] telepresence systems and endpoints by exchanging and negotiating appropriate information. In the context of the requirements in this document and related solution documents, this includes both point to point SIP sessions as well as SIP based conferences as described in the SIP conferencing framework [RFC 4353] and the SIP based conference control [RFC 4579] specifications. It is important for you to be aware that 4353 is informational, however, 4579 is a BCP, thus it should be supported. [/MB2] * about dictating architectural choices >> In the Introduction section, "/It is not the intention of CLUE >> >> to dictate telepresence architectural and implementation >> choices./" I would propose to erase "architectural choice" and >> >> to leave only "implementation choice". The CLUE framework >> should provide some reference architecture for SIP-based >> telepresence systems in order to let them interoperate, so I >> would not say that CLUE is not intended to dictate >> architectural choice. >> >> [MB] I agree. [/MB] >> > > [CNG] I would prefer to leave the existing text. I believe that was the > original intention. > [MB] I don't know what you mean by "original intention"? We have a WG deliverable for a framework which does introduce some architectural concepts. Clearly, we aren't prescribing implementation choices. But, we do lay out a model/architecture/framework for the solution. I think we should stick with the text that the majority agrees with. Also, please keep in mind that this is an informational document, thus it's setting the context for the solution, but defines nothing normative per se. [/MB] > > ..snip.. > > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --047d7b6221ea38692f04e8610d48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      My responses below [MB2].

      Mary


      On Thu, Oct 10, = 2013 at 12:16 AM, Christian Groves <Christian.Groves@nteczone.= com> wrote:
      Hello,

      Please see my comments below.

      Regards, Christian


      On 9/10/2013 10:03 PM, Mary Barnes wrote:
      Hi Roberta,

      Thank you for your review comments. I apologize for the delay in responding= . I've been traveling for the past 3+ weeks and seem to be processing m= y emails LIFO.

      My responses are below [MB].

      Thanks,
      Mary.


      On Mon, Sep 23, 2013 at 8:16 AM, Roberta Presta <roberta.presta@unina.it <mailt= o:roberta.pres= ta@unina.it>> wrote:

      =A0 =A0 Hi all,

      =A0 =A0 in the following some comments to the requirements draft.

      =A0 =A0 =A0 * about the interworking telepresence systems
      =
      =A0 =A0 =A0 =A0 In the Introduction section (page 3, third paragraph), it i= s
      =A0 =A0 =A0 =A0 stated that the purpose of the document is to provide
      =A0 =A0 =A0 =A0 requirements for enabling interworking between /"SIP-b= ased
      =A0 =A0 =A0 =A0 [RFC3261] telepresence systems"/. We should describe/d= efine

      =A0 =A0 =A0 =A0 here in a more precise way these systems, by saying for
      =A0 =A0 =A0 =A0 example that they are "built upon" centralized SI= P-based
      =A0 =A0 =A0 =A0 conferencing systems as defined in RFC4353 (the "confe= rence"
      =A0 =A0 =A0 =A0 definition in the following refers to this RFC). We should<= br> =A0 =A0 =A0 =A0 explicitely mention that we are not dealing with "sign= aling
      =A0 =A0 =A0 =A0 agnostic" frameworks, if this is the case, i.e. if we = leverage
      =A0 =A0 =A0 =A0 SIP as the only signaling protocol for the basic session =A0 =A0 =A0 =A0 management.

      [MB] Good point. =A0How about something like the following change:
      OLD:
      =A0 =A0The purpose of this document is to describe the requirements for a =A0 =A0specification that enables interworking between different SIP-based<= br> =A0 =A0[RFC3261] telepresence systems, by exchanging and negotiating
      =A0 =A0appropriate information.

      NEW:
      =A0 =A0The purpose of this document is to describe the requirements for a =A0 =A0specification that enables interworking between different SIP-based<= br> =A0 =A0[RFC3261] telepresence systems by exchanging and negotiating
      =A0 =A0appropriate information. =A0In the context of these requirements and= related
      =A0 =A0solutions, the SIP telepresence systems are expected to support the = SIP conferencing
      =A0 =A0framework [RFC 4353] and SIP based conference control [RFC 4579] .

      [CNG] I don't agree that it is expected that telepresence systems suppo= rt RFC4353 and 4579. CLUE should be able to be used without these. Especial= ly in the case of point to point CLUE calls. The use of RFC4353 and RFC4579= shouldn't be precluded however.
      [MB2] I would agree for a point to point, so we adj= ust the wording to accommodate that. =A0However, our WG is explicitly chart= ered to be based on SIP Conferencing. =A0Text from the charter:=A0
      =A0=A0"=A0WG will create specifications for SIP-based conferencing s= ystems"
      I would suggest the following new tex= t to be explicit about point to point.=A0
      NEW:
      =A0 =A0The purpose of this do= cument is to describe the requirements for a
      =A0 =A0specification that enabl= es interworking between different SIP-based
      =A0 =A0[RFC3261] telepresence systems an= d endpoints by exchanging and negotiating
      =A0 =A0appropriate information. = =A0In the context of the requirements in this document and=A0
      =A0 =A0related solution docum= ents, =A0this includes both point to point SIP sessions as well as SIP base= d=A0
      =A0 =A0confe= rences as described in=A0the SIP = conferencing
      =A0 =A0framework [RFC 4353] and th= e SIP based conference control [RFC 4579] specifications.=A0

      It is important for you to be aware that 4353 is = informational, however, 4579 is a BCP, thus it should be supported.=A0
      [/MB2]

      =A0 =A0 =A0 * about dictating architectural choices
      =A0 =A0 =A0 =A0 In the Introduction section, "/It is not the intention= of CLUE

      =A0 =A0 =A0 =A0 to dictate telepresence architectural and implementation
      =A0 =A0 =A0 =A0 choices./" I would propose to erase "architectura= l choice" and

      =A0 =A0 =A0 =A0 to leave only "implementation choice". The CLUE f= ramework
      =A0 =A0 =A0 =A0 should provide some reference architecture for SIP-based =A0 =A0 =A0 =A0 telepresence systems in order to let them interoperate, so = I
      =A0 =A0 =A0 =A0 would not say that CLUE is not intended to dictate
      =A0 =A0 =A0 =A0 architectural choice.

      [MB] I agree. [/MB]

      [CNG] I would prefer to leave the existing text. I believe that was the ori= ginal intention.
      [MB] I don't know what you = mean by "original intention"? =A0 =A0 We have a WG deliverable fo= r a framework which does introduce some architectural concepts. =A0Clearly,= we aren't prescribing implementation choices. =A0But, we do lay out a = model/architecture/framework for the solution. =A0I think we should stick w= ith the text that the majority agrees with. Also, please keep in mind that = this is an informational document, thus it's setting the context for th= e solution, but defines nothing normative per se.=A0
      [/MB] =A0

      ..snip..


      _______________________________________________
      clue mailing list
      clue@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/clue
      --047d7b6221ea38692f04e8610d48-- From pkyzivat@alum.mit.edu Thu Oct 10 08:01:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388E921F9CEA for ; Thu, 10 Oct 2013 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.237 X-Spam-Level: X-Spam-Status: No, score=-0.237 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYKII6W+dzWK for ; Thu, 10 Oct 2013 08:01:50 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id BEDBC11E8176 for ; Thu, 10 Oct 2013 08:01:25 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id bNew1m0060vyq2s5AT1REG; Thu, 10 Oct 2013 15:01:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id bT1Q1m00M3ZTu2S3RT1QEM; Thu, 10 Oct 2013 15:01:25 +0000 Message-ID: <5256C143.2020403@alum.mit.edu> Date: Thu, 10 Oct 2013 11:01:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roberta Presta References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> <5255B2F5.1050200@alum.mit.edu> <52568997.9070308@unina.it> In-Reply-To: <52568997.9070308@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381417285; bh=V39DXcGIoLhpJ+5bi+6hPwgsFcLxWDTAMv69rFYeH7g=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QjoG8ai2TfEATZ5mEBxpacM5l4aSYdvP0jv+NxUqhAOsAa+S9AthPmsCi1Z55jcne PSObC0huKcLnKp5gsMkzruAiCLQ/Vd9I9YkDMJ75qH3RPqi3qx8hTzD+D9KZk0de9q hx1uoR8Na5P7pAfjN8EnZejabwm2SKWOtqsnbRGNR0a2wPfyZH93wP9td5kxiKBqJx ZnWLC6aArOpG+TMuA9If8dZmOrvb6HCIeKFTMpIU3g9beIz/QpAT2nUPcPXPPO1+gD 1eipMvI0UVTkbSjmhtL8tj+NdP8fC7JiH9Ko+KH9IDvo1lNoVQJXEQqFRhb8uiVctB HKwNAOKyfpmYw== Cc: clue@ietf.org Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 15:01:55 -0000 Hi Roberta, On 10/10/13 7:03 AM, Roberta Presta wrote: > Hi Paul, > > I will prepare some slides for the next design team meeting to discuss > the updates to the protocol draft. Thanks. This is a key piece, and needs thorough discussion. Some realtime discussion may help stimulate more email discussion. > Please see inline for further comments. > > Il 09/10/2013 21:48, Paul Kyzivat ha scritto: >> >> Section 3: >> >> This describes this as a client-server protocol, with the MC being the >> client and the MP being the server. But in reality we are usually in >> the situation where both ends have both an MC and MP role. And their >> messages are mixed on the same channel. I think it is necessary to >> address this as a single peer-to-peer protocol containing one or two >> nested client-server sub-protocols. >> >> The p2p protocol can be just a mux/demux that sorts messages into one >> or the other of the sub-protocols. (I guess the rule is that ADV and >> RESPONSE are sent to the MC state machine, while RESPONSE, RE-ADV and >> OPTIONS are sent to the MP state machine.) > The demux rule should be: > - from the MC to the MP: OPTIONS, CONFIGURE, READV (only requests) > - from the MP to the MC: ADV, RESPONSE (only notifications and responses) > We have not considered yet the ack/nack mechanism needed to address the > DTLS/SCTP channel issues. I don't think we need an ack/nak for the channel, because the channel is reliable. But I think we need application level confirmation that the message was received and understood. If one message always immediately triggers sending of another, then that can serve as the ack. (E.g., if ADV always triggers an *immediate* CONF or RE-ADV.) If not, then I think something needs to be added. I don't think we want to require the message sender to wait indefinitely to learn whether the request it sent was acceptable to the recipient. And we need some way to deal with errors detected by the channel, when writing or reading. I think those can be treated as events to a state machine, triggering a suitable state transition. But these can't be associated specifically with the MC or MP. >> And presumably channel failures, and ill-formed messages that can't be >> sorted to one of the sub-protocols need to be dealt with at this >> level. (And then they may affect the state of the sub-protocols.) >> >> Alternatively, we *could* consider using two channels, each one being >> client-server. >> >> Section 5: >> >> What causes an MC to come into existence? Does every clue endpoint >> have one? Or is it optional. (E.g., a provider-only device.) >> >> Conversely, is it an error to not get an Advertisement? Couldn't there >> be consumer-only devices? >> >> Its certainly possible to make the protocol work with these being >> optional or required. But the details are different, so we need to >> choose. > I see your point. A CLUE endpoint can surely be also provider-only or > consumer-only. We have a choice. We can allow consumer-only and provider-only. Or we can say every endpoint must run a state machine for each. If so, then and endpoint that wants to be consumer-only will send an "empty" ADV, and an endpoint that wants to be provider-only will send an "empty" CONF. There are some small efficiency gains possible if we support consumer-only and provider-only. But they may be offset by added complexity in negotiating those modes. > We have considered that the peer-to-peer CLUE channel is created between > at least an MC and an MP (since, otherwise, it is useless to set up it). > However, that presupposes that during the channel set up phase it is > possible to understand when the involved parties are both consumer-(or > provider-) only, and in that cases the channel should not be created. If we want to make the determination outside of the protocol, then the most straightforward way I see is to use a separate channel for each MP. If an endpoint wants to be a MP then it initiates a channel. That channel is used asymmetrically, with the initiator being the MP and the other end being the MC. (This is actually anti-client-server, because the server is initiating the channel. But I suppose it could be done the other way, with the consumer initiating the channel.) Or we continue with our current plan to use a single channel for both. But then we must either assume both ends are both MC and MP, or else we must have some explicit mechanism to negotiate that. > If we remove that hypotesis that can lead us in trouble, we have still a > way out with the current draft. > Indeed, when the channel is ready, it is the MC side that starts the > CLUE dialogue with an OPTIONS request to align with the MP about the > version and the extensions to be used within the session. > If both parties are provider-only, the current (only) way to detect that > condition is that the channel is inactive for a time that fires N > timeouts of the MP machine (no OPTIONS received). That is unpleasant. > On the other hand, the current (only) way to detect that both peers are > consumer-only is that there is no answer to the OPTIONS request. > But alternatives can be considered. Some other ways: 1) Each side sends an OPTIONS, regardless of whether it wants to be MC, MP, or both. The MC, and MP roles are then negotiated by the OPTIONS exchanges. (This is what I previously proposed.) But then we need a different state machine for this, because the message doesn't belong to either the MC or MP state machines. 2) One side sends an OPTIONS, and the other responds to it. I don't like this approach, because its asymmetric, and there is no obvious way to decide which end sends. 3) We could start out assuming both sides are both MC and MP. Both sides send an initial ADV (possibly empty, and perhaps indicating that it will always be empty because the sender doesn't want to be an MP.) Then the other side could respond. The response could be a normal MC response. Or it could be a special response that says "I don't want to be an MC". In that latter case, both ends would shut down the state machine. Any of these could be made to work. >> The message has to be parsed (at least in part) in order to determine >> that it is an advertisement. ISTM most parse errors will occur then. >> So I think they show up in the missing state machine I talk about >> above re Section 3. I suppose there may be some (probably semantic) >> errors that are detected after knowing the message is an >> advertisement. Handling those would belong in this state machine. >> >> I see that a CONF is required in response to an ADV. Is it your intent >> that this is to be sent soon (less than human response time)? Or is it >> your expectation that it is ok for this to be delayed long enough to >> allow human interaction and choice? (Which could be several minutes, >> or more.) I think this is an important distinction to make clear. >> > The CONF request, in the form depicted in the protocol draft, is not > conceived as a response to the ADV. > It is a request of configuration that can be sent only after an > ADVERTISEMENT has been received. However, after a first ADV has been > received, a CONF request can be issued also without receiving a new ADV > if, for example, the MC wants to change the something in the current > configuration. > Actually, we have not made any hypotesis about when issuing a CONF. We > rather assume that the CONF is simply issued when it is ready, i.e. when > the ADV has been parsed and interpreted and the desired streams have > been "translated" in the CONF message. That can happen after an > automatic elaboration, for example according to some policy of the > receiver, or after a human configuration, it the MC party has some > software designed to enable a human selection of the desired features. OK. If it is your intent that the CONF can be arbitrarily delayed, or not sent at all, then I propose that we need a separate response message to the ADV. It can't be RESPONSE, because that would screw up sorting message types between state machines. But there could be separate ADV-RESPONSE and CONF-RESPONSE messages, with similar content. It would then be expected that a response is sent promptly to an ADV or CONF, and failure to receive one in a timely way would be a protocol error requiring some remedial action. Thanks, Paul > Thank you, > > Roberta > >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From Mark.Duckworth@polycom.com Thu Oct 10 14:23:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99B221E8092 for ; Thu, 10 Oct 2013 14:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aipSsu-jVW4t for ; Thu, 10 Oct 2013 14:23:36 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA0C11E80ED for ; Thu, 10 Oct 2013 14:23:33 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 10 Oct 2013 14:23:32 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" Date: Thu, 10 Oct 2013 14:23:30 -0700 Thread-Topic: [clue] MCC in framework? Thread-Index: Ac7D2CfHUg9sdJsfTwuuO1ZpUL26rgCJTfYg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60379FD76@CRPMBOXPRD07.polycom.com> References: <524B9464.7060708@nteczone.com> <52537EA6.2090700@nteczone.com> In-Reply-To: <52537EA6.2090700@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] MCC in framework? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 21:23:43 -0000 I'm interested in moving forward with the MCC ideas. In the mailing list d= iscussion, I think there was some support for: 1. MCC concept in general 2. Allowing advertisement of MCs without an encoding group 3. MCC attribute maxcaptures 4. Consumer ability to choose subset of MCs in an MCC I'm not sure about the policy and synch-id attributes. They probably need = more discussion. And we didn't discuss the relation to simultaneous transm= ission sets. I need to look at that again, as I didn't understand that sec= tion the first time (in draft-groves-clue-multi-content-00). Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Monday, October 07, 2013 11:40 PM > To: clue@ietf.org > Subject: Re: [clue] MCC in framework? >=20 > Does anyone have any further comments / questions on the MCC? If people > have concerns it would be good to know them so that they can be addressed > before the upcoming IETF meeting. >=20 > Regards, Christian >=20 > On 2/10/2013 1:35 PM, Christian Groves wrote: > > Hello all, > > > > We've had some discussion on the mailing list regarding the MCC > > concept? The response seems to be cautiously positive. Is this > > something that people are happy to move forward with in the framework? > > > > I'd be happy to work with Mark for some text for the framework. At > > least if there's text then we can iron out any issues. > > > > There is still the issue of full updates vs deltas but I don't think > > that's a specific problem of the MCC concept. > > > > Regards, Christian > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Oct 10 16:43:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B13D21F9950 for ; Thu, 10 Oct 2013 16:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3wSWTD10itr for ; Thu, 10 Oct 2013 16:43:35 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id BA97F11E818D for ; Thu, 10 Oct 2013 16:43:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAGQ6V1J20Xsy/2dsb2JhbAANTIM/whuBNoMaAQEEAQEBNRsVBgoBEAsSDxYIBwkDAgECARUfAw4GDQEFAgEBF4d3pwmTLASPRweEIwOTZkKZFw Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 10:13:22 +1030 Message-ID: <52573B92.4050801@nteczone.com> Date: Fri, 11 Oct 2013 10:43:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:43:36 -0000 Hello Mary, ..snip.. > > > NEW: > The purpose of this document is to describe the > requirements for a > specification that enables interworking between different > SIP-based > [RFC3261] telepresence systems by exchanging and negotiating > appropriate information. In the context of these > requirements and related > solutions, the SIP telepresence systems are expected to > support the SIP conferencing > framework [RFC 4353] and SIP based conference control [RFC > 4579] . > > > [CNG] I don't agree that it is expected that telepresence systems > support RFC4353 and 4579. CLUE should be able to be used without > these. Especially in the case of point to point CLUE calls. The > use of RFC4353 and RFC4579 shouldn't be precluded however. > > [MB2] I would agree for a point to point, so we adjust the wording to > accommodate that. However, our WG is explicitly chartered to be based > on SIP Conferencing. Text from the charter: > " WG will create specifications for SIP-based conferencing systems" > I would suggest the following new text to be explicit about point to > point. > NEW: > The purpose of this document is to describe the requirements for a > specification that enables interworking between different SIP-based > [RFC3261] telepresence systems and endpoints by exchanging and > negotiating > appropriate information. In the context of the requirements in > this document and > related solution documents, this includes both point to point SIP > sessions as well as SIP based > conferences as described in the SIP conferencing > framework [RFC 4353] and the SIP based conference control [RFC > 4579] specifications. > > It is important for you to be aware that 4353 is informational, > however, 4579 is a BCP, thus it should be supported. > [/MB2] [CNG] I'm happy with your suggestion, it covers the point to point case and removes "expected to support". > > * about dictating architectural choices > In the Introduction section, "/It is not the intention > of CLUE > > to dictate telepresence architectural and implementation > choices./" I would propose to erase "architectural > choice" and > > to leave only "implementation choice". The CLUE framework > should provide some reference architecture for SIP-based > telepresence systems in order to let them > interoperate, so I > would not say that CLUE is not intended to dictate > architectural choice. > > [MB] I agree. [/MB] > > > [CNG] I would prefer to leave the existing text. I believe that > was the original intention. > > [MB] I don't know what you mean by "original intention"? We have a > WG deliverable for a framework which does introduce some architectural > concepts. Clearly, we aren't prescribing implementation choices. > But, we do lay out a model/architecture/framework for the solution. > I think we should stick with the text that the majority agrees with. > Also, please keep in mind that this is an informational document, thus > it's setting the context for the solution, but defines nothing > normative per se. > [/MB] [CNG] By original intention I mean the original text "It is not the intention of CLUE to dictate telepresence architectural and implementation choices." This is the current text we have "stuck" to. The change isn't just about removing "architectural" from the requirements its also the suggested change to the framework. The current framework document describes a framework for a "protocol" not an overall architectural description of a SIP telepresence system. I think there's enough in the framework rather than adding a discussion on overall SIP telepresence system architecture. That work would be non-trivial. > > ..snip.. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Christian.Groves@nteczone.com Thu Oct 10 16:57:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297BC21F9B57 for ; Thu, 10 Oct 2013 16:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FMjeFAY36Dg for ; Thu, 10 Oct 2013 16:57:34 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 3240021F8F61 for ; Thu, 10 Oct 2013 16:57:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPY9V1J20Xsy/2dsb2JhbAANTIM/whuBNoMZAQEBBAEBATUbGwQGAQwECxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBiA6nDJMsBI9HBwaEHQOtPw Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 10:27:30 +1030 Message-ID: <52573EE2.5070107@nteczone.com> Date: Fri, 11 Oct 2013 10:57:22 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Duckworth, Mark" References: <524B9464.7060708@nteczone.com> <52537EA6.2090700@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60379FD76@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60379FD76@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC in framework? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2013 23:57:35 -0000 Hello Mark, Thanks for the support. With respect to policy I agree it needs more discussion on the specifics. I think we've discussed it with Christer regarding the ability to specify (1st most active speaker, etc). Are you OK with the general capability of allowing a policy attribute/s to be specified against an MCC? The sync-id attribute I guess is a form of a policy that indicates that a group of MCCs (who have the same sync-id) will send media from the same source at the same time. MCCs can be used within the STS like normal captures. The text in Section 3.1.8 from the MCC draft on MCC and STSs largely addresses the issues related to section 2.7. Basically today there is an issue that we can label a CSE as switched which means that the captures will be sent at different times. However if we put those captures in an STS it indicates that they all can be sent simultaneously which wouldn't be the case. Using the MCC concept would avoid this, i.e. no need for "switched" on a CSE. Regards, Christian On 11/10/2013 8:23 AM, Duckworth, Mark wrote: > I'm interested in moving forward with the MCC ideas. In the mailing list discussion, I think there was some support for: > 1. MCC concept in general > 2. Allowing advertisement of MCs without an encoding group > 3. MCC attribute maxcaptures > 4. Consumer ability to choose subset of MCs in an MCC > > I'm not sure about the policy and synch-id attributes. They probably need more discussion. And we didn't discuss the relation to simultaneous transmission sets. I need to look at that again, as I didn't understand that section the first time (in draft-groves-clue-multi-content-00). > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Monday, October 07, 2013 11:40 PM >> To: clue@ietf.org >> Subject: Re: [clue] MCC in framework? >> >> Does anyone have any further comments / questions on the MCC? If people >> have concerns it would be good to know them so that they can be addressed >> before the upcoming IETF meeting. >> >> Regards, Christian >> >> On 2/10/2013 1:35 PM, Christian Groves wrote: >>> Hello all, >>> >>> We've had some discussion on the mailing list regarding the MCC >>> concept? The response seems to be cautiously positive. Is this >>> something that people are happy to move forward with in the framework? >>> >>> I'd be happy to work with Mark for some text for the framework. At >>> least if there's text then we can iron out any issues. >>> >>> There is still the issue of full updates vs deltas but I don't think >>> that's a specific problem of the MCC concept. >>> >>> Regards, Christian >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Oct 10 18:04:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F05821F9D74 for ; Thu, 10 Oct 2013 18:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvqi1YkRLUJX for ; Thu, 10 Oct 2013 18:04:44 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 096CB11E815F for ; Thu, 10 Oct 2013 18:04:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAF5NV1J20Xsy/2dsb2JhbAANTIM/whEJgTaDGQEBAQQBAQEXHhsbBAYNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQEXh3enEpMpBI1+C4E5DAaEHQOiU4psgVQBBAIC Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 11:34:39 +1030 Message-ID: <52574E9E.6000701@nteczone.com> Date: Fri, 11 Oct 2013 12:04:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> <525578E9.6010500@alum.mit.edu> <009901cec511$73984d00$5ac8e700$@gmail.com> <5255AD6F.8070302@alum.mit.edu> In-Reply-To: <5255AD6F.8070302@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 01:04:46 -0000 With regards to not allocating resources isn't that what RFC 6871 and the latent configuration attribute is for? i.e. Latent Configuration: A latent configuration indicates which combinations of capabilities could be used in a future negotiation for the session and its associated media stream components. Latent configurations are neither ready for use nor offered for actual or potential use in the current offer/answer exchange. Latent configurations merely inform the other side of possible configurations supported by the entity. Those latent configurations may be used to guide subsequent offer/answer exchanges, but they are not offered for use as part of the current offer/answer exchange An Advertiser could offer the "base" audio and video and then the extra captures as latent configurations. The latent configurations can then be linked the CLUE capture through a=label etc. RFC7006 also allows a means of indicating the bandwidth capabilities. This could also be used instead of having CLUE provide this. Regards, Christian On 10/10/2013 6:24 AM, Paul Kyzivat wrote: > On 10/9/13 1:03 PM, Roni Even wrote: >> Hi, >> Some quick points, I still need to look more into the options and I >> was busy >> this week and could not attend the Tuesday call. >> >> As for Paul concern about the resource allocation when providing the >> encoding is SDP , I think that this is not an issue since the m-lines >> specify sendonly streams to be used by the advertisement (section 6 >> examples >> of the signaling draft) > > My understanding of how when/how the bandwidth is managed is pretty > fuzzy. But it would be nice if it isn't a problem in this case. > > Reserving ports, ICE, etc. is still an issue, but bundle will help > with that. > > Thanks, > Paul > >> My general view on the encoding was not favorable from the start. I >> could >> not understand why we need the resource management as part of CLUE. >> My past >> experience was that trying to optimize resource per each codec is not >> easy >> and it is better to use abstract compute units that are codec >> independent >> but allow for multiplications of the unit based on capabilities. For >> example >> H.264 CIF will be one unit and H.264 HD will use 4 units and VP8 HD >> will use >> 4 units (not real numbers just an example), still I am not sure why >> in CLUE >> where we wanted to address relations between streams (spatial) we >> invest so >> much in resource management. >> >> Roni >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Paul Kyzivat >>> Sent: 09 October, 2013 6:40 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Expressing encoding information in CLUE >>> >>> Rob, >>> >>> Thanks for digging into this and getting the discussion started. >>> This is an important decision, so we need some vigorous discussion. I'm >>> looking for feedback from everybody that is actively involved in this. >>> >>> I've been on both sides of this. I've pursued the encoding-in-SDP >>> approach >> in >>> the signaling document. In part because of the consequences that showed >>> up in doing that I've been pushing the exploration of the >>> alternative(s). >> Now >>> we have that. >>> >>> With the encoding-in-SDP approach I remain disturbed by the need for >>> the >>> advertiser to commit media resources (ports, bandwidth) for all the >>> encodings it wants to mention in an advertisement. I think this >>> could be >> quite >>> burdensome, especially for an MCU, that may be advertising many more >>> options than any one endpoint is likely to use. This will be less of a >> problem >>> with bundling, but it still may be a burden wrt bandwidth >>> commitments. It >>> would be unfortunate if the MCU must limit itself in the number of >>> encodings it offers to avoid the call being blocked for demanding >>> too much >>> bandwidth. >>> >>> OTOH, I appreciate Rob's concern over reinventing syntax for codec >> specific >>> constraints. >>> >>> There is no perfect answer here - we must pick our poison. >>> >>> I'm not going to make a choice of my own now (maybe ever). I want to >>> see >>> what others say. >>> >>> Thanks, >>> Paul >>> >>> On 10/8/13 2:15 PM, Robert Hansen wrote: >>>> The previous was an attempt at a relatively objective look at the >>>> different syntactic options for conveying encoding information in >>>> CLUE. >>>> However, I do have opinions on the options available. >>>> >>>> The proposal for negotiating both encodings and multiplexing behaviour >>>> in CLUE was included because it's something we have discussed heavily >>>> in the past. However there were good reason we moved away from it - it >>>> provides a CLUE-specific method of multiplexing that won't play well >>>> with the syntax being defined in the wider MMUSIC sphere, as well as >>>> all the problems inhereit with multiplexing on a single m-line. >>>> >>>> The other two options explored use SDP for multiplexing, but one >>>> expressed the encoding limitations in SDP while the other does so in >>>> CLUE. I think both are workable solutions, but my preference is for >>>> the SDP option. >>>> >>>> While the expressing encoding limitations in CLUE approach does >>>> provide a number of advantages: fewer m-lines, fewer O/As, more >>>> accurate encoder limitations and (as Paul pointed out in the design >>>> call today) the ability to express encoder limitations without >>>> committing resources, I think the need to come up with syntax for the >>>> encoding limits in CLUE is a painful one. If these limits can be >>>> expressed in abstract, codec-independent ways then that's one thing, >>>> but each time this issue comes up somewhere the upshot seems to be >>>> that abstract, codec-independent limitations aren't actually possible, >>>> and that would leave us with the need to reinvent syntax for any codec >>> that could be used. >>>> >>>> I'd be very happy to be proved wrong about this, but I don't think the >>>> advantages of expressing the encoding constraints in CLUE are >>>> sufficient to outweight the cost of such codec-specific work, and I >>>> don't think we'll be able to come up with a nice abstraction everyone >> will >>> sign off on. >>>> >>>> Rob >>>> >>>> On 08/10/2013 09:35, Robert Hansen wrote: >>>>> At the design meeting last week I volunteered to take a stab at >>>>> evaluating alternate approaches to conveying all encoding information >>>>> in SDP. The text got a bit long for an email, so I've also attached >>>>> it as a text document. I'll also put together some slides on the >>>>> topic for this call this afternoon. >>>>> >>>>> One of the fundamental issues we have in clue is how to negotiate the >>>>> details of the encodings defined in draft-ietf-clue-framework. Unless >>>>> other entities such as captures, which are unique to CLUE, encodings >>>>> share many properties with limits that are currently expressible in >>>>> SDP, but have additional requirements and limits that are less good >>>>> fits for SDP. One of the >>>>> >>>>> The current assumption we have been working from, as detailed in >>>>> draft-kyzivat-clue-signaling, is that the encodings (defined in >>>>> draft-ietf-clue-framework), will be expressed in SDP and not in the >>>>> CLUE signalling. However, this has only ever been a working >>>>> assumption rather than something we've reached consensus on, and this >>>>> is a fundamental design decision that impacts not just the message >>>>> syntax but also the call flows and state machines inherent in the >>>>> signalling. As such, I volunteered to examine the alternative >>>>> approach, to hopefully allow us to resolve this issue so we can move >>> forward. >>>>> >>>>> To do this I am going to examine two alternate options (for deails of >>>>> the SDP approach see draft-kyzivat-clue-signaling). One is to, where >>>>> possible, negotiate the limits and use of multiple video and audio >>>>> subsessions as part of the CLUE Advertisment/Configure exchange, with >>>>> the negotiated SDP m-lines treated as an 'envelope' subdivided by >>>>> CLUE; this approach was the one that had more initial exploration by >>>>> the CLUE WG before we moved towards the SDP approach. The other >>>>> approach is a half-way house that has not yet been explored in any >>>>> detail; this is to negotiate each channel in SDP, but to express the >>>>> encoding constraints within the CLUE signalling. >>>>> >>>>> *** Encodings in CLUE *** >>>>> >>>>> In this approach the encodings available, and the constraints >>>>> associated with them, are expressed in the CLUE Advertisment. The far >>>>> end then selects which encodings they wish to receive, and the limits >>>>> on those encodings as part of the CLUE Configure message. >>>>> >>>>> In the simplest (and, most likely, commonest case) this would allow a >>>>> single sendrecv m-line per media type to be used for all sent and >>>>> received CLUE-controlled streams. The various streams must then be >>>>> demultiplexed; this can be done via explicit SSRC for static streams >>>>> or via an additional header such as appId. SSRC is used in examples; >>>>> replacing these with appId indicators should be roughly equivalent >>>>> for streams with dynamic SSRCs. As such the initial SDP, and then >>>>> Advertiment, might look something like: >>>>> >>>>> EXAMPLE SDP OFFER (from A) >>>>> m=video ... >>>>> ... >>>>> a=ssrc:1234 >>>>> a=ssrc:2345 >>>>> a=ssrc:3456 >>>>> a=sendrecv >>>>> >>>>> EXAMPLE ADVERTISMENT (from A) >>>>> Capture Scene 1: >>>>> Capture 1: Left (Encoding Group 1) >>>>> Capture 2: Center (Encoding Group 1) >>>>> Capture 3: Right (Encoding Group 1) >>>>> Capture 4: Switched >>>>> Capture Scene Entry 1: 1,2,3 >>>>> Capture Scene Entry 2: 4 >>>>> Simultaneous Sets: 1,2,3,4 >>>>> Encoding Group 1: >>>>> Encoding 1: H264, 1080p30, ssrc=1234 >>>>> Encoding 2: H264, 1080p30, ssrc=2345 >>>>> Encoding 3: H264, 1080p30, ssrc=3456 >>>>> >>>>> The SSRC/appId attributes are ignorable and hence sendable in the >>>>> initial SSRC, though implementations may prefer to leave them out >>>>> initially and then readvertise once CLUE is established. >>>>> >>>>> I've also included SSRCs alongside the encodings. In this case all >>>>> encodings are on the same m-line, but there are scenarios where this >>>>> multiplexing may not be appropriate or even possible, such as the >>>>> disaggregated case when different streams must be sent to different >>>>> IP addresses. In such circumstances there is a need to be able to >>>>> distinguish which encodings can be sent on which m-line. An >>>>> alternative would be to have the SSRCs only in SDP, and use something >>>>> else to tie that to the encodings (such as a label attribute). >>>>> >>>>> Having the encodings split across multiple m-lines will present >>>>> additional challenges, which will be detailed later. For now, >>>>> consider the rest of the simple case. The far end will complete the >>>>> SDP negotiation, and send a Configure message choosing what to >>>>> receive, something like this: >>>>> >>>>> EXAMPLE SDP ANSWER (from B) >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> >>>>> EXAMPLE CONFIGURATION (from B) >>>>> Capture 1, Encoding 1 >>>>> Capture 2, Encoding 2 >>>>> Capture 3, Encoding 3 >>>>> >>>>> At this point the sender can begin sending three media streams, which >>>>> the receiver can demultiplex by SSRC. >>>>> >>>>> However, one major issue remains even for the multiplexed case: how >>>>> to express receiver encode limitations. These are currently expressed >>>>> in SDP, and are defined to apply to a single media stream. However, >>>>> in the case above three streams are being sent to that port, and we >>>>> have to decide what those limits mean. >>>>> >>>>> One answer would be that it provides the *overall* limit, but this >>>>> quickly runs into problems. One issue is that not all parameters can >>>>> be sensibly subdivided: for H264 max-br and max-mbps could be divided >>>>> into three relatively easily, but max-fs makes less sense. And even >>>>> avoiding this, it would allow the far end to validly send a single >>>>> stream that matched the combined limit, which the receiver might not >>>>> be able to cope with; existing 3-screen systems often have three >>>>> seperate decoders that cannot pool their decode resource (eg, they >>>>> might be able to decode three 720p streams, but not one 1080p >>>>> stream). >>>>> >>>>> As such a better answer is that the SDP receive limits express the >>>>> limit for *any* individual stream; in the example above each of the >>>>> three streams could be sent at up to 720p30. However, this still >>>>> poses an >>>>> issue: what happens if the receiver wants to receive different >>>>> capture encodings with different constraints. In the example above >>>>> most receivers will probably want all three streams at similar >>>>> resolutions, but in the scenario where a device wants to receive one >>>>> primary capture encoding to view full-screne and six >>>>> capture-encodings to use as small picture-in-picture insets then the >>>>> receiver needs to be able to express these different constraints. >>>>> >>>>> One option is for the SDP codec limit to provide a set of maxima for >>>>> any given stream, but then be able to express *additional* limits for >>>>> each capture encoding as part of the Configure message; a highly >>>>> simplified version might look like this: >>>>> >>>>> EXAMPLE CONFIGURATION (from B) >>>>> Capture 1, Encoding 1, 720p30 >>>>> Capture 2, Encoding 2, 360p30 >>>>> Capture 3, Encoding 3, 360p30 >>>>> >>>>> These would provide additional constraints on what could be sent for >>>>> each stream; they could only lower (not raise) the constraints >>>>> expressed in SDP. On the plus side, the 'encodings in CLUE' approach >>>>> will mean we need to create syntax to express codec-specific encoder >>>>> limitations for the Advertise messages, and much of that syntax could >>>>> use here. On the minus side, this means replicating functionality >>>>> that is already part of SDP. >>>>> >>>>> If we don't want to go down the route of re-expressing codec limits >>>>> in CLUE there is another option, which is that receivers that want to >>>>> express different receive limits for different capture encodings they >>>>> wish to receive will need to create new m-lines in the SDP so they >>>>> can differentiate between the capture encodings they want to receive. >>>>> The plus side of this approach is that this is a requirement of the >>>>> 'Encodings in CLUE' approach anyway, as it's needed for the case >>>>> where the initial answerer is a disaggregated system that doesn't >>>>> want to multiplex their streams; these scenarios will also need to >>>>> reoffer with new m-lines and split up the streams. >>>>> >>>>> The downside of this approach is that coming up with a general way to >>>>> mix and match multiple m-line each of which may multiplex different >>>>> streams, and the ability to change the the number of m-lines in use >>>>> and which encodings are multiplexed onto each is painful, to the >>>>> point where I don't have a particularly good handle on it. I've >>>>> included some initial speculation in an appendix at the end of the >>>>> page to avoid eating up too much space here. >>>>> >>>>> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': >>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>> limitations using existing SDP syntax >>>>> * In the straightforward multiplexed case fewer (or no) additional >>>>> O/As and m-lines >>>>> >>>>> Disadvantages: >>>>> * Need to reinvent syntax to express H264 (and any other codec) >>>>> limitations >>>>> * Problems with moving from multiplexed to non-multiplexed (and >>>>> similar) >>>>> * Media-specific information in CLUE messaging, potentially limiting >>>>> interoperability with other ongoing multistream work >>>>> >>>>> *** Encoding Constraints in CLUE *** >>>>> >>>>> This scenario presents a half-way house between the 'Encodings in >>>>> CLUE' >>>>> approach expressed above and the 'Encodings in SDP' approach >>>>> expressed in draft-kyzivat-clue-signaling. In this case there is a >>>>> seperate m-line per stream, just as with the 'Encodings in SDP' >>>>> approach. However, in this approach the encoding constraints are >>>>> expressed in the CLUE Advertisment. >>>>> >>>>> Let us explore the three-screen example from before with this new >>>>> approach. There will be an initial SDP O/A to establish the CLUE >>>>> channel and verify that both sides support CLUE. There is then a new >>>>> SDP offer with an m-line per stream available, and a matching >>> advertisment: >>>>> >>>>> EXAMPLE SDP OFFER (from A) >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=label:A >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=label:B >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=label:C >>>>> a=sendrecv >>>>> >>>>> EXAMPLE ADVERTISMENT (from A) >>>>> Capture Scene 1: >>>>> Capture 1: Left (Encoding Group 1) >>>>> Capture 2: Center (Encoding Group 1) >>>>> Capture 3: Right (Encoding Group 1) >>>>> Capture 4: Switched >>>>> Capture Scene Entry 1: 1,2,3 >>>>> Capture Scene Entry 2: 4 >>>>> Simultaneous Sets: 1,2,3,4 >>>>> Encoding Group 1: >>>>> Encoding 1: H264, 1080p30, label=A >>>>> Encoding 2: H264, 1080p30, label=B >>>>> Encoding 3: H264, 1080p30, label=C >>>>> >>>>> I've used label above to tie the encodings to the m-lines, but this >>>>> could alternately be SSRC (if SSRC was being used), appId (if appId >>>>> were being used) or anything else. >>>>> >>>>> This closely matches the examples in draft-kyzivat-clue-signaling. >>>>> However, the sender can use 'sendrecv' rather than 'sendonly' for the >>>>> new m-lines rather than 'sendonly', as the encoder limits are >>>>> expressed instead in CLUE. This also has the advantage that the CLUE >>>>> syntax for these limits allows the precise H264 send limits to be >>>>> expressed (while SDP limits which parameters can be used in H.264 >>> sendonly). >>>>> >>>>> If the far end wants to receive the three static captures then it >>>>> sends an answer SDP which can accept those, along with a Configure >>>>> message specifying which captures it wants to receive: >>>>> >>>>> EXAMPLE SDP ANSWER (from B) >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> >>>>> EXAMPLE CONFIGURATION (from B) >>>>> Capture 1, Encoding 1 >>>>> Capture 2, Encoding 2 >>>>> Capture 3, Encoding 3 >>>>> >>>>> The receiver no longer needs to express the receive limits in CLUE; >>>>> with an m-line per received stream the standard SDP parameters >>>>> already allow full expression of the limitations. Now it just needs >>>>> to state what encoding it wants to use for each capture it receives. >>>>> >>>>> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we >>>>> consider the other direction (B sendings to A) then if B has three >>>>> streams or fewer then it will not have to make a new SDP offer. For >>>>> instance, if B supported up to two encodings its response could >>>>> instead have been: >>>>> >>>>> EXAMPLE SDP ANSWER (from B) >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=sendrecv >>>>> m=video ... >>>>> ... H264@720p30 >>>>> a=recvonly >>>>> >>>>> And could immediately send an Advertisment with its capture and >>>>> encoding information. A new offer would be needed if B had more >>>>> encodings than A, or if A wanted to change its receive capabilities >>>>> based on the capture encodings it wanted from A. >>>>> >>>>> This approach is very like the 'Encodings in SDP' approach, with the >>>>> following advantages and disadvantages: >>>>> >>>>> Advantages relative to 'Encodings in SDP': >>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>> limitations using existing SDP syntax >>>>> * Many m-lines can be sendrecv, in many cases will need fewer O/As >>>>> >>>>> Disadvantages: >>>>> * Still need to reinvent syntax to express H264 (and any other codec) >>>>> encoding limitations >>>>> >>>>> *** Summary *** >>>>> >>>>> Appealing as the 'Encodings in CLUE' case is when all streams of a >>>>> given media type can be multiplexed onto a single m-line, treating >>>>> SDP as an 'envelope' CLUe can subdivide, I don't believe this >>>>> approach is actually feasible. Also having to support the multiple >>>>> m-line case and be able to sensibly change the number of m-lines is >>>>> painful, while the need to replicate receive codec limits in CLUE >>>>> that are already expressed very capably in SDP is unlikely to be >> popular. >>>>> >>>>> I believe the 'Encoding *constraints* in CLUE' approach is >>>>> considerably more plausible, though the variation from the 'Encodings >> in >>> SDP' >>>>> approach is fairly small. Principly it comes down to whether the work >>>>> required to develop syntax to express the send limits for the various >>>>> codecs in CLUE is worth the added accuracy of what can be expressed >>>>> in CLUE over what is currently available in SDP, along with the >>>>> advantage of less need to add new m-lines (and the associated O/As >>> involved). >>>>> >>>>> *** Appendix *** >>>>> >>>>> Let us first consider the case of wanting to split an offered set of >>>>> streams. The sender (A) can send up to five capture encodings, and so >>>>> send an SDP offer along the lines of: >>>>> >>>>> m=video ... >>>>> ... >>>>> a=ssrc:1234 >>>>> a=ssrc:2345 >>>>> a=ssrc:3456 >>>>> a=ssrc:4567 >>>>> a=ssrc:5678 >>>>> a=sendrecv >>>>> >>>>> The receiver (B) wants to receive one of those streams on one m-line, >>>>> three more on a second m-line and the fifth not at all. The rules of >>>>> O/A mean that B must send an initial answer with the single m-line, >>>>> which we won't illustrate here, and then send a new offer. Some >>>>> method must be provided to show what streams are to be received >>>>> where; in this case I'm using the max-ssrc draft: >>>>> >>>>> m=video ... >>>>> ... >>>>> a=max-recv-ssrc:{*:1} >>>>> a=sendrecv >>>>> m=video ... >>>>> ... >>>>> a=max-recv-ssrc:{*:3} >>>>> a=sendrecv >>>>> m=video ... 0 >>>>> >>>>> A will then need to reorder their allocation of SSRCs to m-lines to >>>>> sensibly fit this. And if later in the call B decides that it now >>>>> wants to multiplex all of the streams this will need to be done in >>>>> reverse, with B sending a new offer with only one activevideo m-line >>>>> and suitable max-recv-ssrc value and hope that A will correctly >>>>> interpret this. This reallocation of streams between m-lines is the >>>>> part I think will be difficult to define normatively. >>>>> >>>>> Rob >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Oct 10 20:16:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A63711E810F for ; Thu, 10 Oct 2013 20:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLt8jdyYepmR for ; Thu, 10 Oct 2013 20:16:51 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id AEF6A11E810A for ; Thu, 10 Oct 2013 20:16:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMBAAdtV1J20Xsy/2dsb2JhbAANS4M/TMFPgTiDGQEBAQQBAQEkCwEFGxsJAQ8CCxgJDAoIBwkDAgECAQkMHxETBgIBAQWIBAWnGpMzBI4KgUAKhBkDmTSUC4Fd Received: from ppp118-209-123-50.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.123.50]) by ipmail05.adl6.internode.on.net with ESMTP; 11 Oct 2013 13:46:48 +1030 Message-ID: <52576D96.3050606@nteczone.com> Date: Fri, 11 Oct 2013 14:16:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> In-Reply-To: <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 03:16:52 -0000 Hello Simon and Roberta, Thanks for the updates. I had a look and have a few comments below: 1. Sect.1 bullet 2 : The Config allows captures and encodings to be selected so I would propose to update the wording: 2. enabling a MC to request the desired multimedia streams from the offering MP. 2. Sect.3 1st para: The MC not only requests the stream but receives them. I propose updating the text: ...while the client side is represented by the Media Consumer, which requests the media streams. 3. Sect. 3 3rd para: Similar comment to 1 above. I propose rewording: The MC selects the desired streams coming from the MP by using... 4. Sect. 3.x: The tables have "Type". Is this really needed as it is explained in the text. Plus 3.2 the message name is "Response" and the type is "Response". It seems superfluous. 5. Sect.3.3: Nit: Rescription should be "Description" 6. Sect 3.x: Are we missing a message? There is a Response for a Configure but there is no response to an Advertisement. If the MC receives an Advertisement there should at least be an indication that it was received OK. Why would a response to a Configure or an Advertisement be handled differently. I think the RE-ADV should only be used when the MC needs to refresh its state, not for indicating that there is a Advertisement message syntax problem, etc. Note: this is a similar comment as Paul's regarding the application level ACK. I don't think that a ADV needs an immediate CFG. 7. Sect.5 2nd para: What is meant by ".. if the number of trials is below the retry threshold...? 8. Sect.5 3rd para: As per 6 I think that rather than RE-ADV a "ADV-RESP" would be sent indicating an error condition. A MP should be the one to decide to determine if another ADV is sent. 9. Sect.5 3rd para: This indicates that if there is an error with the ADV the MC goes from state "receive ADV" to "IDLE". What doesn't appeared to be covered is what happens if the MC is in "IN CALL" state when it receives the ADV and there's an error? I would assume that rather than go to IDLE on error that it would go back to "IN CALL"? The state could potentially be affected by what error is received. 10. Sect.5 General: The term "CALL" is used. For me this encompasses the entire session. i.e. to be "IN CALL" it would assume the CLUE negotiation is done, the media streams are configured and media is flowing etc. As this is describing a CLUE state machine should we instead use CLUE specific terminology? i.e. "IN CALL" -> "CAPTURES NEGOTIATED" etc. 11. Sect. 6 General: As per 6 above I think there should be an application level response, either saying success or error. Once that is received then it should wait for a CONFIG or RE-ADV. 12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that has error when it is an a IN CALL state I would expect that it remain in an in call state. Rather than go back to IDLE. 13 General: Do we need to define the scope of the states that they only cover CLUE? or do they have further scope. E.g. If the CLUE state is Terminated does this indicate some other behaviour that the MP or MC should do? i.e. send updated SIP O/A to remove media. Btw, I'm not suggesting this extended scope. 14 Sect 7. Para.1: Nit - Suggested update: "... the message cannot be processed ." Some processing has to be done to determine version. 15 Sect 7. Para.3: Nit - "subsequet" -> "subsequent" 16 Sect 7. Para.3: The changes need to be backwards compatible not only in terms of schema but also semantically and procedurally as well. 16 Sect 7. Para.4: I'm not a big supporter of having versions related to different CLUE protocol drafts. Compliance to a CLUE version isn't just based on the version of the schema. e.g. what if we change the procedural handling of an existing XML element? The schema wouldn't change. I'd prefer simply working towards v1.0. 17 Sect 7. Para.5: nits: "ascpect"->"aspect", "explicitely"->"explicitly", "would up"-> "would up" 18 Sect 8.1 para 4: It mentions here that " Elements or attributes from unknown namespaces MUST be ignored". If the MP or MC receives such an element I would expect that an error be returned to the ADV or CFG message it contained or? 19 Sect 8.1: I guess each of the last 3 bullets should be possible depending on the type of data. I think that we need to separate the actual syntax and structures (i.e. CS, CSEs, STSs etc) from the Captures attributes. It should be possible to create new attributes or update their value through an extension mechanism rather than need to update the protocol version. Is this what is meant by the 3rd bullet? Updates to the syntax and structures should need a new version. 19 Sect 8.2: I think a new message does need a new version so this should be the ONLY chance. 20 Sect 9 Para.3: Nit instatiated->instantiated. 21 Sect 9: I think we had some previous discussion that the OPTIONs should only occur once at the start of the CLUE channel. This didn't seem to be covered. 22 Sect 9: Why is the MC responsible for sending the OPTIONS message? I would have thought that as the MP sends the ADV (which is effectively the first message) that it would send it? Regards, Christian On 8/10/2013 10:21 PM, Simon Pietro Romano wrote: > ...here it is. > > Simon > > Inizio messaggio inoltrato: > >> *Da: *internet-drafts@ietf.org >> *Oggetto: **New Version Notification for >> draft-presta-clue-protocol-02.txt* >> *Data: *08 ottobre 2013 13:20:31 GMT+02:00 >> *A: *Roberta Presta > >, Simon Pietro Romano >> >, Simon Romano >> > >> >> >> A new version of I-D, draft-presta-clue-protocol-02.txt >> has been successfully submitted by Roberta Presta and posted to the >> IETF repository. >> >> Filename:draft-presta-clue-protocol >> Revision:02 >> Title:CLUE protocol >> Creation date:2013-10-08 >> Group:Individual Submission >> Number of pages: 26 >> URL: >> http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt >> Status: http://datatracker.ietf.org/doc/draft-presta-clue-protocol >> Htmlized: http://tools.ietf.org/html/draft-presta-clue-protocol-02 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-02 >> >> Abstract: >> The CLUE protocol is an application protocol conceived for the >> description and negotiation of a CLUE telepresence session. The >> design of the CLUE protocol takes into account the requirements and >> the framework defined, respectively, in [I-D.ietf-clue-framework] and >> [I-D.ietf-clue-telepresence-requirements]. The companion document >> [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as >> well as on the SIP/SDP session establishment phase. We herein focus >> on the application level perspective. Message details, together with >> the behavior of both the Media Provider and the Media Consumer are >> discussed. >> >> >> >> >> 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 >> . >> >> The IETF Secretariat >> >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Oct 11 06:45:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E81421E8109 for ; Fri, 11 Oct 2013 06:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.28 X-Spam-Level: X-Spam-Status: No, score=-0.28 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El17N-ZL5dNL for ; Fri, 11 Oct 2013 06:45:03 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2521E81D0 for ; Fri, 11 Oct 2013 06:45:01 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta04.westchester.pa.mail.comcast.net with comcast id bpDn1m00d1HzFnQ54pl0xg; Fri, 11 Oct 2013 13:45:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id bpl01m0063ZTu2S3apl0qG; Fri, 11 Oct 2013 13:45:00 +0000 Message-ID: <525800DB.1010104@alum.mit.edu> Date: Fri, 11 Oct 2013 09:44:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: SIPCORE , CLUE References: <5257A241.7060607@ericsson.com> In-Reply-To: <5257A241.7060607@ericsson.com> X-Forwarded-Message-Id: <5257A241.7060607@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381499100; bh=9nKga5WS+Two+BW2d7jooF+2ak9qqWvHQxu8/n+E7eU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qNJoEBCesyDTv9vpUH09WlY+nSu5bo6b6QfhYe/ElERZi2MiZm4bJ4W/dLeebw5Js BKLPyDF8YvdhhLaPBZI3EHwGM/DN5cT9zRqWNmRRnM5e7SRF5y9fxBhKrLdgliu+k9 cFh3U5A9ortQriGQlbokIo6OwB3h7rcLkkEmL1DeRkcHzNKSTfdiF01dfRTe8ZfBHN 84Vug1G9NlS26Tfj3dpYgbKhwinzanxN57wpmrPVn+o4mcFB23k398ZsXcY+Qyms17 tv45MSNrjQmLixuHzxoLRajZSvveNF67CG/4GJUiTCaby8yXXWHmfBfWrayA9gZJRn XEvIbSGycx2vw== Subject: [clue] [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 13:45:08 -0000 People, there is a need for more nominees/volunteers to run for RAI AD, as replacement for Gonzalo, whose term is expiring. If you are interested, or know somebody you would like to run, please speak up. Thanks, Paul -------- Original Message -------- Subject: [RAI] Fwd: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Fri, 11 Oct 2013 09:44:23 +0300 From: Gonzalo Camarillo To: Folks, we need more volunteers (see email below). If you are thinking of running but still have some doubts about it, feel free to talk with me (or with any of the former RAI ADs) and we will be happy to clarify everything for you. Cheers, Gonzalo -------- Original Message -------- Subject: NOMCOM 2013 - UPDATED 2nd Call for Nominations - APP, OAM, RAI, TSV Date: Tue, 8 Oct 2013 11:45:14 -0700 From: NomCom Chair Reply-To: To: IETF Announcement List CC: UPDATE: nominations are too sparse in several of the IESG areas: APP, OAM, RAI, and TSV. If you know one or more of those areas, exercise your social network and submit nominations. We'll be very grateful! Is there someone you work with at IETF who has leadership potential and a growing track record? Please read this Nomcom call for nominations and consider nominating her or him. Or several folks! Deadline for nominations is October 18. Nominate soon to give your nominee(s) plenty time to fill in the questionnaire. If you're nominated, even if you support the present incumbent, being reviewed by Nomcom is great IETF experience. The questionnaire offers a chance to think about IETF and about your area. Whether or not your candidacy progresses this time, you'll have gained some valuable insights, and you'll have contributed greatly. This process only works because many IETFers take part; please join in. Lots more, including which positions are open, how to make a nomination (including nomination of yourself), and how to send us your feedback on the desired expertise, follows. IETFers, let's hear from you! Make nominations, accept nominations! If you have any questions about the process, feel free to get in touch with me. Best regards, Allison for the Nomcom Allison Mankin Nomcom Chair 2013-14 ----- The Info You Need for Nominating ----- The 2013-14 Nominating Committee (Nomcom) is seeking nominations from now until October 18, 2013. The open positions being considered by this year's Nomcom can be found later in this section, and also on this year's Nomcom website: https://datatracker.ietf.org/nomcom/2013/ Information about the desired expertise for positions is here: https://datatracker.ietf.org/nomcom/2013/expertise Nominations may be made by selecting the Nominate link at the top of the Nomcom 2013 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2013/nominate/ Note that nominations made using the web tool require an ietf.org datatracker account. You can create a datatracker ietf.org account if you don't have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ Nominations may also be made by email to nomcom13 at ietf.org. If you nominate by email, please include the word "Nominate" in the Subject and indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you are making the nomination. If you use email, please use a separate email for each person you nominate, and for each position (if you are nominating one person for multiple positions). Self-nomination is welcome! No need to be shy. Nomcom 2013-14 will follow the policy for "Open Disclosure of Willing Nominees" described in RFC 5680. As stated in RFC 5680: "The list of nominees willing to be considered for positions under review in the current Nomcom cycle is not confidential". Willing nominees for each position will be listed in a publicly accessible way - anyone with a datatracker account may access the lists. In all other ways, the confidentiality requirements of RFC 3777/BCP10 remain in effect. All feedback and all Nomcom deliberations will remain confidential and will not be disclosed. In order to ensure time to collect sufficient community feedback about each of the willing nominees, nominations must be received by the Nomcom on or before October 18, 2013. Please submit your nominations as early as possible for the sake of your nominees, as we've set the questionnaire submission deadline for October 25, 2013. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which we are accepting nominations: IAOC Chris Griffiths IAB Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) Please be resourceful in identifying possible candidates for these positions, as developing our talent is a very crucial requirement for the IETF. Also, please give serious consideration to accepting nominations you receive. The summaries of the desired expertise for the positions, developed by the respective bodies, are found at: https://datatracker.ietf.org/nomcom/2013/expertise/ In addition to nominations, the Nomcom seeks community input on the positions themselves. We need and welcome the community's views and input on the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. You can send us email about this to nomcom13 at ietf.org, and we will use this feedback actively. Thank you for your help in nominating a great pool of strong and interesting nominees! _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From Mark.Duckworth@polycom.com Fri Oct 11 08:28:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5DA11E8216 for ; Fri, 11 Oct 2013 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoAeJb7zPIzE for ; Fri, 11 Oct 2013 08:28:33 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B1C8E11E818A for ; Fri, 11 Oct 2013 08:28:32 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 11 Oct 2013 08:28:32 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 11 Oct 2013 08:28:30 -0700 Thread-Topic: redefining scene-switch-policy? Thread-Index: Ac7Gk4kwLd10+OdaSv2nqpDhMV/UvQ== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60379FF86@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D60379FF86CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] redefining scene-switch-policy? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:28:38 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60379FF86CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Christian, Roni, Weiwei, draft-groves-clue-multi-content-00 section 3.3.3 has a proposal for renamin= g the scene-switch-policy attribute, and also proposal to rewrite the descr= iption of what this attribute means. I think this proposal overall is good= , in that it gives a more precise description without changing the intent. But I have a few questions about the proposal (listed below). Also I wonde= r if alternatively we could just remove the scene-switch-policy (and propos= ed capture source synchronization attribute) altogether, if we decide to mo= ve forward with the multiple content capture (MCC) with sync-id attribute. = It seems to me that by using MCC with sync-id it can accomplish the same t= hing in more general way without needing scene-switch-policy. What do othe= rs think? Questions on section 3.3.3 (these questions are moot if we decide to remove= this attribute altogether): 1. I think it would be useful to add a reference back to the use case= document, saying the motivation for this is to enable the use cases relate= d to site-switch and segment-switch as described in the use case document. = Would that help readers understand what this is all about? 2. I don't understand the statement "However it is assumed that each = capture within the CSE will contain the same number and set of sources." I= s this talking about an MCC and the other MCs that could contribute to it? = Why would each capture in a CSE have to contain the same number and set of= sources? 3. I don't understand the two paragraphs about the "Switched" attribu= te and "Composed" attribute. It sounds like a proposal to subtly change th= e meaning of these attributes if the advertiser also uses the Capture Sourc= e Synchronization attribute. I don't get the intent of this, can you expla= in further? Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60379FF86CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Christian, Roni,= Weiwei,

       

      draft-groves-clue-multi-content-00 section 3.3.3 has a proposa= l for renaming the scene-switch-policy attribute, and also proposal to rewr= ite the description of what this attribute means.  I think this propos= al overall is good, in that it gives a more precise description without cha= nging the intent.

       

      <= p class=3DMsoNormal>But I have a few questions about the proposal (listed b= elow).  Also I wonder if alternatively we could just remove the scene-= switch-policy (and proposed capture source synchronization attribute) altog= ether, if we decide to move forward with the multiple content capture (MCC)= with sync-id attribute.  It seems to me that by using MCC with sync-i= d it can accomplish the same thing in more general way without needing scen= e-switch-policy.  What do others think?

       

      Questions on section 3.3.3 (= these questions are moot if we decide to remove this attribute altogether):=

       

      1.       I= think it would be useful to add a reference back to the use case document,= saying the motivation for this is to enable the use cases related to site-= switch and segment-switch as described in the use case document.  Woul= d that help readers understand what this is all about?

      = 2.       I don’t understand the statement “However it is assu= med that each capture within the CSE will contain the same number and set o= f sources.”  Is this talking about an MCC and the other MCs that= could contribute to it?  Why would each capture in a CSE have to cont= ain the same number and set of sources?

      3.       I do= n’t understand the two paragraphs about the “Switched” at= tribute and “Composed” attribute.  It sounds like a propos= al to subtly change the meaning of these attributes if the advertiser also = uses the Capture Source Synchronization attribute.  I don’t get = the intent of this, can you explain further?

       

      Mark

      = --_000_49E45C59CA48264997FEBFB29B6BC2D60379FF86CRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Fri Oct 11 08:58:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF321F9E6A for ; Fri, 11 Oct 2013 08:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHcLEnSFZQ0f for ; Fri, 11 Oct 2013 08:58:00 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id EC44621F9E9F for ; Fri, 11 Oct 2013 08:57:28 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 11 Oct 2013 08:57:27 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 11 Oct 2013 08:57:25 -0700 Thread-Topic: [clue] Example of MCC - consumer driven layout and switching Thread-Index: Ac7GlyGiBcQ/qNbPQ+CtRCRMKR9bHw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 15:58:09 -0000 I'm branching this topic off the MCC discussion, keeping just a small secti= on of previous email. I have another suggestion to consider about making media switching decision= s - see below. Has anybody else considered an idea like this? > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Robert Hansen > Sent: Monday, September 30, 2013 12:43 PM > To: clue@ietf.org > Subject: Re: [clue] Example of MCC > > > On 28/09/2013 1:04 AM, Duckworth, Mark wrote: > >> One downside to this approach is that every change the MCU makes in > >> how it assigns contributing VCs to an MCC (e.g. make a switch based > >> on current talker) could result in the consumer renderer needing to > >> change how it maps decoder output to display locations. I need to > >> think more about if this would really be a problem or not. >=20 > [RH] My issue with using the spatial coordinates of the MCC is that it re= quires > the MCU to anticipate the rendering desires of the endpoint, as the MCU w= ill > need to advertise MCCs with spatial coordinates that allow the endpoint t= o > do what it wants to do. My concern has always been that this may lead to > huge numbers of MCCs and capture scene entries if the MCU is trying to > anticipate potential layouts by the endpoint. I agree it is good if the MCU does not have to anticipate the rendering (la= yout) desires of the endpoint consumer. So I consider if it is better if t= he consumer can make even more of the decisions, including dynamically sele= cting which source capture should be included in an MCC. draft-groves-clue= -multi-content-00 says "The Consumer may or may not want to receive all th= e indicated captures. Therefore it can choose to receive a sub-set of capt= ures indicated by the MCC." This means the consumer can choose, in a confi= gure message, to receive the one particular capture it wants at that moment= , for each MCC. And it can send new configure messages any time, to change= this choice. I think this would not require any SDP exchanges. If the consumer makes these choices (which still must be consistent with th= e advertisement), then the provider doesn't have to make any switching choi= ces any more. The consumer can make its choices based on its own local pol= icy for layout and rendering. But the consumer would need some more information about current activity in= the conference in order to make these decisions. The consumer would need = to know about audio activity, for example in the form of a "most recent tal= ker list" or something like that, in order to make the decisions about whic= h MC it wants to receive within each MCC. I don't know of any existing sta= ndard way to convey that information. It seems to me a provider could send= a "most recent talker list" to a consumer via the CLUE channel. Is anybod= y interested in pursuing this idea? Mark From Mark.Duckworth@polycom.com Fri Oct 11 11:57:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3552521F9DC9 for ; Fri, 11 Oct 2013 11:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYz81UXaZSed for ; Fri, 11 Oct 2013 11:56:46 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB711E819D for ; Fri, 11 Oct 2013 11:56:39 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 11 Oct 2013 11:56:39 -0700 From: "Duckworth, Mark" To: Mary Barnes , CLUE Date: Fri, 11 Oct 2013 11:56:37 -0700 Thread-Topic: [clue] Fwd: Comments on CLUE Framework Thread-Index: Ac6kOdf8jfzpE/TvTcmuZnORHV6PpAieOwMg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6037A010A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> <521D7313.6030609@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D6037A010ACRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 18:57:03 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D6037A010ACRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mary, I'm updating the framework according to this discussion. But there are a f= ew things still open: 1. For your comment number 2, you offered to take a pass at moving so= me information out of the Introduction into a new section or into the overv= iew. That would be very helpful to me, thanks. 2. You offered to create a new ascii diagram based on an old one from= section 5 of the -02 version 3. Using All Caps for defined terms - personally I agree with you I p= refer the terms as lower case (both as an editor and as a reader). Does an= ybody else have input to this? Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Wednesday, August 28, 2013 5:59 PM To: Christian Groves Cc: CLUE Subject: Re: [clue] Fwd: Comments on CLUE Framework HI Christian, Thanks for your comments - my responses are below [MB2]. Mary. On Tue, Aug 27, 2013 at 10:48 PM, Christian Groves > wrote: Hello Mary, Please see my responses below. Regards, Christian On 28/08/2013 1:53 AM, Mary Barnes wrote: Hi folks, In reviewing the FW in order to tease out specific security threats that a = CLUE solution must address, I came up with a set of comments that I would l= ike the WG to consider. Below is the thread of discussion. Additional feedb= ack (both agreeing with the proposal or not - with details if you don't agr= ee) from the WG is necessary in order for Mark to include these changes. As= noted, I will provide some concrete text to go along with a couple of the = suggestions. Please send feedback no later than Sept. 3rd CoB. No responses= will be interpreted as support for the changes. Of course, there will be an opportunity to provide comments on the updated = version of the document as well later, but it's always helpful to get that = feedback before incorporating changes. Regards, Mary --as an individual ---------- Forwarded message ---------- From: *Mary Barnes* >> Date: Tue, Aug 27, 2013 at 10:18 AM Subject: Re: Comments on CLUE Framework To: "Duckworth, Mark" >> Cc: Paul Kyzivat >> Thanks for the response. I have a few responses below [MB]. I will forward = the comments to the list to get feedback from the WG. Mary. On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark >> wrote: Hi Mary, Thanks for the good suggestions. In general, all your suggestions make sense to me. More comments below. Mark *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com >] *Sent:* Wednesday, August 21, 2013 2:23 PM *To:* Duckworth, Mark *Cc:* Paul Kyzivat *Subject:* Comments on CLUE Framework So, here are the comments I have on the framework based on my re-read to tease out specifics for the security requirements. One major thing I noticed is that some of the structural concerns I have are with regards to some of the bigger changes made between the -08 and -09. Again, I looked at diffs after the various revisions were submitted and thought the content was okay at the time. But, as I'm now re-reading from beginning to the end (for the first time in a long time), there are some areas that I really stumbled over and I think some more reorganization/editorial work is needed before we could forward this doc for publication. Having been a gen-art reviewer for a decade, I think similar issues would be raised on the document by other directorate reviewers (and ADs) if we don't make a few changes. I wanted to vet these with you prior to posting to the WG mailing list. Paul - I'm reviewing this from the perspective that was discussed on WG chairs mailing list with regards to doing multiple reviews as part of the PROTO process. Mary. Comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Major: ------- 1) The abstract needs some beefing up, including setting some context. Per my comment 3 below, I think it's important to highlight that the protocol outlined in this document augments and does not replace SIP O/A. I would suggest to update the text in the Abstract something like the following. : OLD: This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. NEW: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system, receiving system or intermediate system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. */[Duckworth, Mark] sounds good./* /*[CNG] CLUE is point to point, (i.e. sent from one endpoint and terminated= at another)*/ so there is no intermediate system from a CLUE perspective. = I would strike the text regarding intermediate system. [MB2] My understanding was that intermediate system is something line an MC= U or conference focus. However, I think you are correct in that sending s= ystem and receiving system are sufficient. I also double checked and we don= 't use the term intermediate system in the requirements or use cases expect= in the Heterogeneous system use case when it's talking about transcoding. = [/MB2] 2) Introduction: I really stumbled over the level of detail that the document jumps into in the Introduction (which is before any terminology). It goes from a high level description of the problem, highlighting that this document provides a framework based on the use cases and requirements, directly to the statement: "Conceptually distinguished are Media Providers and Media Consumers". I also think the level of detail does not belong in the introduction. To me that's more overview/motivation. Previously, the introduction provided some text as to what is in the remainder of the document. I think some of the old text needs to be pulled back into this introduction and the text starting with the "Conceptually" paragraph might serve very well in a "Motivation" section just prior to the overview (after the terminology section). I also think the "Conceptually" sentence could be replaced with text that provides a better introduction to the section, perhaps linking the term "consumer" to "receiver" and "provider" to "sender" that are mentioned in the abstract text I suggested above. Maybe something like the following: OLD: Conceptually distinguished are Media Providers and Media Consumers. NEW: This document introduces the term Media Provider to represent the entity that is sending the media and Media Consumer to represent the entity that is receiving the media. */[Duckworth, Mark] sounds good. But it will take some work to figure out detailed changes between introduction and overview, and bringing back some old text./* [MB] Yeah, I know. I can make a pass at that if you would find that helpful= . [/MB] [CNG] OK in theory, I'll wait for the concrete text. *//* 3) The fact that SIP and SDP offer/answer are used for basic session setup as well as when needed during the session (as described in detail in solution documents) isn't highlighted early enough or often enough. Given we've had lots of folks thinking we were trying to invent something new entirely, I think it's really important for this be quite explicit early on. I think this relates to additional text that should be in the introduction. I think something like the following will be sufficient: NEW: This document identifies the protocols necessary to achieve the functionality per the use cases and requirements. The basic session setup for the use cases is based on SIP [RFC 3261] and SDP offer/answer [RFC 3264]. The details with regards to this signaling are provided in the solution documents. In addition to basic SIP & SDP offer/answer, CLUE specific signaling is required to exchange the information describing the multiple media streams. The details of this signaling and the information required to be exchanged is described in subsequent sections of this document. */[Duckworth, Mark] sounds good. We tried to say this about using SDP O/A, but not until the end of section 4. It does seem better to say it earlier./* /*[CNG] I think we should also make it clear that whilst "SIP and SDP O/A" = are mainly discussed it does not prevent CLUE from being used in networks w= here there are other call controls i.e. H.32x, WebRTC, what ever the future= holds.... */ [MB2] I don't disagree with what you say but I don't think we should say an= ything about that given our charter, which limits the work to SIP. That's o= pening up the question as to how that will work, whether additional specifi= cation is required,etc. [/MB2] Minor: -------- 1) General: I realize that at some point, someone changed all the terms to appear as formal names - e..g., capitalized. Personally, I prefer just having the terms all lower case as I find it easier to read that way. However, the RFC editor leaves the choice to the document editor, but it needs to be consistent. So, another pass is needed as I noticed a few that weren't caps that should be and some that were caps that shouldn't be. For example, in the "Conceptually" paragraph I refer to above, "Renderer" is in Caps, but it's not defined as a reserved word in the terminology and I'm assuming that the intent is to only have nouns in all caps? You will find it awkward if you try to change every occurrence of the reserved words as sometimes it just won't read right (which is another reason to just use lower case). */[Duckworth, Mark] I don't care either way. I think it was Stephan who first suggested capitals, in the old terminology document./* [MB] Again, either way is okay. But, there are some places where it's not a= ll caps. I also think using lower case is easier just from a basic editing = standpoint as it's more natural IMHO to just type the words and not have to= CAP. [/MB] [CNG] It can be helpful to have capitalised terms to distinguish when you'r= e talking about a entity Renderer vs a function "render". *//* 2) Introduction: The text in the intro (3rd para) (that I'm suggesting to move to Motivation section) that starts with "Motivations" reads a little funky. I suggest to reword something like: OLD: Motivations for this document (and, in fact, for the existence ofthe= CLUE protocol) include: NEW: The motivations for the framework outlined in this document include the= following: */[Duckworth, Mark] sounds good/* /*[CNG] OK*/ 3) Introduction: List item (1). I was going to suggest rewording (as it reads as if the endpoints described are only specific to this document), but it's not clear to me exactly what that item is trying to say. Can it be changed to something like the following and still mean what is intended? [As an aside "Media Renderer" isn't a reserved word - I think perhaps if you add a definition for "Renderer" that would help. I actually think that's probably necessary anyways as I think it's important to distinguish "Media Renderer" from "Media Consumer"]. OLD: (1) Endpoints according to this document can, and usually do, have mult= iple Media Captures and Media Renderers, that is, for example,multiple came= ras and screens. While previous system designs were able to set up calls t= hat would light up all screens and cameras (or equivalent), what was missing was a mechanism that can associate th= e Media Captures with each other in space and time. NEW: (1) Endpoints in telepresence systems typically have multiple Media Cap= tures and Media Renderers, e.g., multiple cameras and screens. While previ= ous system designs were able to set up calls that would capture media using= all cameras and display media on all screens, for example, there is no mec= hanism that can associate these Media Captures with each other in space and= time. */[Duckworth, Mark] Yes, I think that says the intent better./* /*[CNG] */I'd propose a slight reword "Endpoints in telepresence systems ty= pically have multiple Media Capture and Media Render devices, e.g., multipl= e cameras and screens. ..." [MB2] That sounds good to me. [/MB] 4) Section 4, last two paragraphs. I'm really wondering how much needs to be said (if anything) about "legacy" in this document. This document is defining what we need for CLUE. The signaling solution document will of course get into how this works. But, I think we could just delete the next to last paragraph and condense the one on RTP to reference the WG RTP mapping mapping document */[Duckworth, Mark] okay/* /*[CNG] I don't think one paragraph describing this fall back in the framew= ork is too much. I think its helpful to explain fallback behaviour. */ [MB2] If you read it in the context of that section, it doesn't quite seem = to fit. It leaves more questions than providing answers in my opinion. It= seems to be some leftover text from when the document had a lot more detai= l - e.g., the text about legacy devices is totally unnecessary as they aren= 't referenced elsewhere in the framework any longer. I think perhaps the i= dea of fallback when the device doesn't support CLUE can be stated much mor= e concisely. I don't have a proposal right off, but will think about it. U= nless someone else has suggestions. [/MB2] 5) Somewhat General. There was a diagram in Section 5 in the -02 version that was dropped in the -03. I really think that more diagrams would help to understand this stuff. */[Duckworth, Mark] That was the precursor to this. The -02 diagram doesn't really say much, but I could try to update it. The one below is a bit much to convert to ASCII./* [MB] I can convert that to ascii art. I did all the diagrams in RFC 5239. T= his is just a tad more complicated than some of those. [/MB] *//* *//* 6) Per my other email, I believe these should all be normative references and RFC 3264 needs to be added. [CNG] ??? [MB2] Sorry, there was another email exchange that I hadn't yet sent to the= list about making this document standards track and adding some more refer= ences. I'll send that now. [/MB2] _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_49E45C59CA48264997FEBFB29B6BC2D6037A010ACRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Mary,

      I’m updating the framew= ork according to this discussion.  But there are a few things still op= en:

      1.  =      For your com= ment number 2, you offered to take a pass at moving some information out of= the Introduction into a new section or into the overview.  That would= be very helpful to me, thanks.

      2.       <= ![endif]>You offered to create a new ascii diagram based on an old o= ne from section 5 of the -02 version

      3.       Using All Caps for defined terms – personally I = agree with you I prefer the terms as lower case (both as an editor and as a= reader).  Does anybody else have input to this?

      =

       

      Mark

       <= /o:p>

      From: clue-bounces@= ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
      = Sent: Wednesday, August 28, 2013 5:59 PM
      To: Christian Gro= ves
      Cc: CLUE
      Subject: Re: [clue] Fwd: Comments on CLUE = Framework

       =

      HI Christian,

       

      Thanks = for your comments - my responses are below [MB2].

      =

       

      M= ary.

       

      On Tue, Aug 27, 2013 at 10:= 48 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:=

      Hello Mary,

      Please see my responses below.<= br>
      Regards, Christian



      O= n 28/08/2013 1:53 AM, Mary Barnes wrote:

      Hi folks,
      In reviewing the FW in order to tease out specific security threats t= hat a CLUE solution must address, I came up with a set of comments that I w= ould like the WG to consider. Below is the thread of discussion. Additional= feedback (both agreeing with the proposal or not - with details if you don= 't agree) from the WG is necessary in order for Mark to include these chang= es. As noted, I will provide some concrete text to go along with a couple o= f the suggestions. Please send feedback no later than Sept. 3rd CoB. No res= ponses will be interpreted as support for the changes.

      Of course, th= ere will be an opportunity to provide comments on the updated version of th= e document as well later, but it's always helpful to get that feedback befo= re incorporating changes.

      Regards,
      Mary
      --as an individual
      =
      ---------- Forwarded message ----------

      From: *Mary Barnes* <mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes= @gmail.com>>
      Date: Tue, Aug 27, 2013 at 10:18 AM
      Subject: R= e: Comments on CLUE Framework

      To: "Duckworth, Mark" <Mark.Duckworth@pol= ycom.com <mailto:Mark.Duckworth@polycom.com>>
      Cc: Paul Kyzivat <= ;pkyzivat@alum.m= it.edu <mailto:pkyzivat@alum.mit.edu>>


      Thanks for the response.= I have a few responses below [MB]. I will forward the comments to the list= to get feedback from the WG.

      Mary.

      On Mon, Aug 26, 2013 a= t 4:26 PM, Duckworth, Mark <Mark.Duckworth@polycom.com <mailto:Mark.Duckworth@polycom.c= om>> wrote:

          Hi Mary,

          Th= anks for the good suggestions. In general, all your suggestions
        &= nbsp; make sense to me.

          More comments below.

      &n= bsp;   Mark

          *Fr= om:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
          <mailto:mary.ietf.barn= es@gmail.com>]
          *Sent:* Wednesday, August 21, 2013 2= :23 PM
          *To:* Duckworth, Mark
          *Cc:* Paul K= yzivat
          *Subject:* Comments on CLUE Framework



      &nbs= p;   So, here are the comments I have on the framework based on my
      =     re-read to tease out specifics for the security requirements.= One
          major thing I noticed is that some of the structural = concerns I
          have are with regards to some of the bigger cha= nges made between
          the -08 and -09. Again, I looked at diff= s after the various
          revisions were submitted and thought t= he content was okay at the
          time. But, as I'm now re-readin= g from beginning to the end (for
          the first time in a long = time), there are some areas that I really
          stumbled over an= d I think some more reorganization/editorial work
          is neede= d before we could forward this doc for publication. Having
         = been a gen-art reviewer for a decade, I think similar issues would
      &nbs= p;   be raised on the document by other directorate reviewers (and ADs= )
          if we don't make a few changes. I wanted to vet these wi= th you
          prior to posting to the WG mailing list.

      &nb= sp;   Paul - I'm reviewing this from the perspective that was discusse= d
          on WG chairs mailing list with regards to doing multiple= reviews
          as part of the PROTO process.

         = ; Mary.

          Comments:

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

          Major:

          -------=

          1) The abstract needs some beefing up, including sett= ing some
          context. Per my comment 3 below, I think it's imp= ortant to
          highlight that the protocol outlined in this doc= ument augments and
          does not replace SIP O/A. I would sugge= st to update the text in
          the Abstract something like the f= ollowing. :

          OLD:

              &n= bsp;This document offers a framework for a protocol that enables

      &nb= sp;       devices in a telepresence conference to interopera= te by specifying

              the relationships betwe= en multiple media streams.

          NEW:

          T= his document defines a framework for a protocol to enable devices
       =   in a telepresence conference to interoperate. The protocol enables<= br>    communication of information about multiple media streams = so a
          sending system, receiving system or intermediate syst= em can make
          reasonable decisions about transmitting, selec= ting and rendering
          the media streams. This protocol is use= d in addition to SIP
          signaling for setting up a telepresen= ce session.

          */[Duckworth, Mark] sounds good./*<= /p>

      /*[CNG] CLUE is point to point, (i.e. = sent from one endpoint and terminated at another)*/ so there is no intermed= iate system from a CLUE perspective. I would strike the text regarding inte= rmediate system.

      [MB2] My understan= ding was that intermediate system is something line an MCU or conference fo= cus.   However, I think you are correct in that sending system and rec= eiving system are sufficient. I also double checked and we don't use the te= rm intermediate system in the requirements or use cases expect in the Heter= ogeneous system use case when it's talking about transcoding.  [/MB2]<= o:p>

      =  

      &n= bsp;   2) Introduction: I really stumbled over the level of detail tha= t
          the document jumps into in the Introduction (which is be= fore any
          terminology). It goes from a high level descripti= on of the
          problem, highlighting that this document provide= s a framework
          based on the use cases and requirements, dir= ectly to the
          statement: "Conceptually distinguished a= re Media Providers and
          Media Consumers". I also think= the level of detail does not belong
          in the introduction. = To me that's more overview/motivation.
          Previously, the int= roduction provided some text as to what is in
          the remainde= r of the document. I think some of the old text needs
          to b= e pulled back into this introduction and the text starting
         = with the "Conceptually" paragraph might serve very well in a
      =     "Motivation" section just prior to the overview (af= ter the
          terminology section). I also think the "Conce= ptually" sentence
          could be replaced with text that pr= ovides a better introduction to
          the section, perhaps linki= ng the term "consumer" to "receiver" and
        &nbs= p; "provider" to "sender" that are mentioned in the abs= tract text I
          suggested above. Maybe something like the fol= lowing:

          OLD:

          Conceptually disting= uished are Media Providers and Media Consumers.

          NEW:
          This document introduces the term Media Provider to rep= resent the
          entity that is sending the media and Media Cons= umer to represent
          the entity that is receiving the media.<= o:p>

          */[Duckworth, Mark] = sounds good. But it will take some work to


          figure out detailed changes between introduction = and overview, and

          br= inging back some old text./*


      [MB] Yeah, I know. I can make a pass at that if you would find that helpf= ul. [/MB]

      [CNG] OK in= theory, I'll wait for the concrete text.


          *//*



          3) The fact that SIP and SDP off= er/answer are used for basic
          session setup as well as when= needed during the session (as
          described in detail in solu= tion documents) isn't highlighted early
          enough or often en= ough. Given we've had lots of folks thinking we
          were tryin= g to invent something new entirely, I think it's really
          im= portant for this be quite explicit early on. I think this
          = relates to additional text that should be in the introduction. I
        =   think something like the following will be sufficient:

       =   NEW:

          This document identifies the protocols ne= cessary to achieve the
          functionality per the use cases and= requirements. The basic
          session setup for the use cases i= s based on SIP [RFC 3261] and SDP
          offer/answer [RFC 3264].= The details with regards to this
          signaling are provided i= n the solution documents. In addition to
          basic SIP & S= DP offer/answer, CLUE specific signaling is required
          to ex= change the information describing the multiple media streams.
        &nb= sp; The details of this signaling and the information required to be
      &nb= sp;   exchanged is described in subsequent sections of this document.<= o:p>

          */[Duckworth, Mark] = sounds good. We tried to say this about using


          SDP O/A, but not until the end of section 4.= It does seem better

          to say it earlier./*

      /*[CNG] I think we should also make it clear that whilst "= ;SIP and SDP O/A" are mainly discussed it does not prevent CLUE from b= eing used in networks where there are other call controls i.e. H.32x, WebRT= C, what ever the future holds.... */

      [MB2] I don't disagree with what you say but I don't think w= e should say anything about that given our charter, which limits the work t= o SIP. That's opening up the question as to how that will work, whether add= itional specification is required,etc.  [/MB2] 


          Minor:

          --------
          1) General: I realize that at some point, someone changed al= l the
          terms to appear as formal names - e..g., capitalized= . Personally,
          I prefer just having the terms all lower cas= e as I find it easier
          to read that way. However, the RFC e= ditor leaves the choice to the
          document editor, but it nee= ds to be consistent. So, another pass
          is needed as I notic= ed a few that weren't caps that should be and
          some that we= re caps that shouldn't be. For example, in the
          "Conce= ptually" paragraph I refer to above, "Renderer" is in Caps,<= br>    but it's not defined as a reserved word in the terminology= and I'm
          assuming that the intent is to only have nouns in= all caps? You
          will find it awkward if you try to change e= very occurrence of the
          reserved words as sometimes it just= won't read right (which is
          another reason to just use low= er case).

          */[Duckwor= th, Mark] I don’t care either way. I think it was

      =


          Stephan who first suggested capitals= , in the old terminology

        &n= bsp; document./*



      [MB] Again= , either way is okay. But, there are some places where it's not all caps. I= also think using lower case is easier just from a basic editing standpoint= as it's more natural IMHO to just type the words and not have to CAP. [/MB= ]

      [CNG] It can be helpful to have capitalised terms to distinguis= h when you're talking about a entity Renderer vs a function "render&qu= ot;.

          *//*



         = ; 2) Introduction: The text in the intro (3rd para) (that I'm
        &nb= sp; suggesting to move to Motivation section) that starts with
        &n= bsp; "Motivations" reads a little funky. I suggest to reword some= thing
          like:

          OLD:

      =

             Motivations for this docume= nt (and, in fact, for the existence ofthe CLUE protocol) include:



       = ;   NEW:

           
          The motivations= for the framework outlined in this document include the following:

        &nb= sp; */[Duckworth, Mark] sounds good/*

      /*= [CNG] OK*/


          3) Int= roduction: List item (1). I was going to suggest rewording
         = (as it reads as if the endpoints described are only specific to
        =   this document), but it's not clear to me exactly what that item is    trying to say. Can it be changed to something like the foll= owing
          and still mean what is intended? [As an aside "= Media Renderer"
          isn't a reserved word - I think perha= ps if you add a definition
          for "Renderer" that w= ould help. I actually think that's probably
          necessary anyw= ays as I think it's important to distinguish "Media
          R= enderer" from "Media Consumer"].

          OLD:
          (1) Endpoints according to this document can, and usual= ly do, have multiple Media Captures and Media Renderers, that is, for examp= le,multiple cameras and screens.  While previous system designs were a= ble to set up calls that would light up all screens and cameras

      &nbs= p;   (or equivalent), what was missing was a mechanism that can associ= ate the Media Captures with each other in space and time.

        &nb= sp; NEW:

           
          (1) Endpoints in tel= epresence systems typically have multiple Media Captures and Media Renderer= s, e.g., multiple cameras and screens.  While previous system designs = were able to set up calls that would capture media using all cameras and di= splay media on all screens, for example, there is no mechanism that can ass= ociate these Media Captures with each other in space and time.

       = ;    

          */[Duckworth, Mark] Yes, I think that says the = intent better./*

      /*[CNG] */I'd propose a= slight reword "Endpoints in telepresence systems typically have multi= ple Media Capture and Media Render devices, e.g., multiple cameras and scre= ens. ..."

      [MB2] T= hat sounds good to me. [/MB] 

       

           
          4) = Section 4, last two paragraphs. I'm really wondering how much
        &nb= sp; needs to be said (if anything) about "legacy" in this documen= t.
          This document is defining what we need for CLUE. The si= gnaling
          solution document will of course get into how this= works. But, I
          think we could just delete the next to last= paragraph and condense
          the one on RTP to reference the WG= RTP mapping mapping document

          */[Duckworth, Mark] okay/*

      /*[CNG] I don't think one paragrap= h describing this fall back in the framework is too much. I think its helpf= ul to explain fallback behaviour. */

      [MB2] If you read it in the context of that section, it does= n't quite seem to fit. It leaves more questions than providing answers in m= y opinion.   It seems to be some leftover text from when the document = had a lot more detail - e.g., the text about legacy devices is totally unne= cessary as they aren't referenced elsewhere in the framework any longer. &n= bsp;I think perhaps the idea of fallback when the device doesn't support CL= UE can be stated much more concisely.  I don't have a proposal right o= ff, but will think about it. Unless someone else has suggestions.  [/M= B2]


          5) Somewhat General. T= here was a diagram in Section 5 in the -02
          version that wa= s dropped in the -03. I really think that more
          diagrams wo= uld help to understand this stuff.

          */[Duckworth, Mark] That was the precursor to this. The -02<= o:p>


          diagram doesnR= 17;t really say much, but I could try to update it. The

          one below is a bit much to convert to A= SCII./*



      [MB] I can convert that to ascii art. I did all the diagrams in= RFC 5239. This is just a tad more complicated than some of those. [/MB]

          *//*

        &nb= sp; *//*



          6) Per my other email, I believe these should al= l be normative
          references and RFC 3264 needs to be added.<= br>

      [CNG] ???

      [MB2] Sorry, there was an= other email exchange that I hadn't yet sent to the list about making this d= ocument standards track and adding some more references.  I'll send th= at now. [/MB2] 

      ____________________________________= ___________
      clue mailing list
      clue@ietf.org
      https://www.ietf.org/mailman/listinfo/clue

       <= /p>

      = --_000_49E45C59CA48264997FEBFB29B6BC2D6037A010ACRPMBOXPRD07pol_-- From pkyzivat@alum.mit.edu Fri Oct 11 12:21:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4279B21E80DA for ; Fri, 11 Oct 2013 12:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plQGSe8HVO+C for ; Fri, 11 Oct 2013 12:21:26 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id D034D21E80FA for ; Fri, 11 Oct 2013 12:21:22 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta10.westchester.pa.mail.comcast.net with comcast id bsc11m0090mv7h05AvMMgc; Fri, 11 Oct 2013 19:21:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id bvMM1m00N3ZTu2S3XvMMsQ; Fri, 11 Oct 2013 19:21:21 +0000 Message-ID: <52584FB0.5060507@alum.mit.edu> Date: Fri, 11 Oct 2013 15:21:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> <525578E9.6010500@alum.mit.edu> <009901cec511$73984d00$5ac8e700$@gmail.com> <5255AD6F.8070302@alum.mit.edu> <52574E9E.6000701@nteczone.com> In-Reply-To: <52574E9E.6000701@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1381519281; bh=zJKJwIfLVs7luEonHpTl1q6BLmUZEQF973qzyTIS/04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lXkYn7LnICvhfbfctOKa6yC0ke3u6TuhNzHejAQjp1/8Kp6MItmznTsls7ilp8aw4 rjjmpt+YaSjn9LHWcPyX2fecp5hbgIQywVBlyO9WTmN2IcPIITx/dEy/sZMipes2b6 NHMd3IagGBErzrvdtvqjIk5iYdt5l4Ahqy9YQpoVHR1LQYSzuOOMTujsiX/pnJwIAS +2rEc5UPdz59A2r8JD3OO8NfjKLR6TPqBw6GiqPGOmZTf+mSG36tmpIFyinD0kfD+Z ZRPOzZd1g5wZw75Ejwf4BTIoifaNqcndCHGYZw2ZaWkOFdmVYboE4jVFYs77aBbhuD XaXeQ1FcL0lBw== Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 19:21:40 -0000 Christian, I had given passing thought to capneg, but no more than that. Its worth discussing. (Note that I don't know much about it.) I have yet to hear of anyone actually using this mechanism. Presumably somebody has. But IMO it remains to be seen if this is going to fly. If somebody can cite deployments that could ease my concerns. If we went that way, then we would have need to reference parts of a latent configuration from the CLUE protocol. I think we would be breaking new ground there. Its highly questionable whether reference to a=label attributes embedded within a latent configuration are well defined. That may be true of references to latent a=mid attributes as well. (In fact, attempting to use the grouping framework within a latent configuration might present difficulties.) This doesn't mean we can't make this work. It does mean its going to take some effort to do so. Thanks, Paul On 10/10/13 9:04 PM, Christian Groves wrote: > With regards to not allocating resources isn't that what RFC 6871 and > the latent configuration attribute is for? i.e. > > Latent Configuration: A latent configuration indicates which > combinations of capabilities could be used in a future negotiation > for the session and its associated media stream components. Latent > configurations are neither ready for use nor offered for actual or > potential use in the current offer/answer exchange. Latent > configurations merely inform the other side of possible > configurations supported by the entity. Those latent configurations > may be used to guide subsequent offer/answer exchanges, but they are > not offered for use as part of the current offer/answer exchange > > > An Advertiser could offer the "base" audio and video and then the extra > captures as latent configurations. The latent configurations can then be > linked the CLUE capture through a=label etc. > > RFC7006 also allows a means of indicating the bandwidth capabilities. > This could also be used instead of having CLUE provide this. > > Regards, > Christian > > > On 10/10/2013 6:24 AM, Paul Kyzivat wrote: >> On 10/9/13 1:03 PM, Roni Even wrote: >>> Hi, >>> Some quick points, I still need to look more into the options and I >>> was busy >>> this week and could not attend the Tuesday call. >>> >>> As for Paul concern about the resource allocation when providing the >>> encoding is SDP , I think that this is not an issue since the m-lines >>> specify sendonly streams to be used by the advertisement (section 6 >>> examples >>> of the signaling draft) >> >> My understanding of how when/how the bandwidth is managed is pretty >> fuzzy. But it would be nice if it isn't a problem in this case. >> >> Reserving ports, ICE, etc. is still an issue, but bundle will help >> with that. >> >> Thanks, >> Paul >> >>> My general view on the encoding was not favorable from the start. I >>> could >>> not understand why we need the resource management as part of CLUE. >>> My past >>> experience was that trying to optimize resource per each codec is not >>> easy >>> and it is better to use abstract compute units that are codec >>> independent >>> but allow for multiplications of the unit based on capabilities. For >>> example >>> H.264 CIF will be one unit and H.264 HD will use 4 units and VP8 HD >>> will use >>> 4 units (not real numbers just an example), still I am not sure why >>> in CLUE >>> where we wanted to address relations between streams (spatial) we >>> invest so >>> much in resource management. >>> >>> Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>>> Paul Kyzivat >>>> Sent: 09 October, 2013 6:40 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Expressing encoding information in CLUE >>>> >>>> Rob, >>>> >>>> Thanks for digging into this and getting the discussion started. >>>> This is an important decision, so we need some vigorous discussion. I'm >>>> looking for feedback from everybody that is actively involved in this. >>>> >>>> I've been on both sides of this. I've pursued the encoding-in-SDP >>>> approach >>> in >>>> the signaling document. In part because of the consequences that showed >>>> up in doing that I've been pushing the exploration of the >>>> alternative(s). >>> Now >>>> we have that. >>>> >>>> With the encoding-in-SDP approach I remain disturbed by the need for >>>> the >>>> advertiser to commit media resources (ports, bandwidth) for all the >>>> encodings it wants to mention in an advertisement. I think this >>>> could be >>> quite >>>> burdensome, especially for an MCU, that may be advertising many more >>>> options than any one endpoint is likely to use. This will be less of a >>> problem >>>> with bundling, but it still may be a burden wrt bandwidth >>>> commitments. It >>>> would be unfortunate if the MCU must limit itself in the number of >>>> encodings it offers to avoid the call being blocked for demanding >>>> too much >>>> bandwidth. >>>> >>>> OTOH, I appreciate Rob's concern over reinventing syntax for codec >>> specific >>>> constraints. >>>> >>>> There is no perfect answer here - we must pick our poison. >>>> >>>> I'm not going to make a choice of my own now (maybe ever). I want to >>>> see >>>> what others say. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/8/13 2:15 PM, Robert Hansen wrote: >>>>> The previous was an attempt at a relatively objective look at the >>>>> different syntactic options for conveying encoding information in >>>>> CLUE. >>>>> However, I do have opinions on the options available. >>>>> >>>>> The proposal for negotiating both encodings and multiplexing behaviour >>>>> in CLUE was included because it's something we have discussed heavily >>>>> in the past. However there were good reason we moved away from it - it >>>>> provides a CLUE-specific method of multiplexing that won't play well >>>>> with the syntax being defined in the wider MMUSIC sphere, as well as >>>>> all the problems inhereit with multiplexing on a single m-line. >>>>> >>>>> The other two options explored use SDP for multiplexing, but one >>>>> expressed the encoding limitations in SDP while the other does so in >>>>> CLUE. I think both are workable solutions, but my preference is for >>>>> the SDP option. >>>>> >>>>> While the expressing encoding limitations in CLUE approach does >>>>> provide a number of advantages: fewer m-lines, fewer O/As, more >>>>> accurate encoder limitations and (as Paul pointed out in the design >>>>> call today) the ability to express encoder limitations without >>>>> committing resources, I think the need to come up with syntax for the >>>>> encoding limits in CLUE is a painful one. If these limits can be >>>>> expressed in abstract, codec-independent ways then that's one thing, >>>>> but each time this issue comes up somewhere the upshot seems to be >>>>> that abstract, codec-independent limitations aren't actually possible, >>>>> and that would leave us with the need to reinvent syntax for any codec >>>> that could be used. >>>>> >>>>> I'd be very happy to be proved wrong about this, but I don't think the >>>>> advantages of expressing the encoding constraints in CLUE are >>>>> sufficient to outweight the cost of such codec-specific work, and I >>>>> don't think we'll be able to come up with a nice abstraction everyone >>> will >>>> sign off on. >>>>> >>>>> Rob >>>>> >>>>> On 08/10/2013 09:35, Robert Hansen wrote: >>>>>> At the design meeting last week I volunteered to take a stab at >>>>>> evaluating alternate approaches to conveying all encoding information >>>>>> in SDP. The text got a bit long for an email, so I've also attached >>>>>> it as a text document. I'll also put together some slides on the >>>>>> topic for this call this afternoon. >>>>>> >>>>>> One of the fundamental issues we have in clue is how to negotiate the >>>>>> details of the encodings defined in draft-ietf-clue-framework. Unless >>>>>> other entities such as captures, which are unique to CLUE, encodings >>>>>> share many properties with limits that are currently expressible in >>>>>> SDP, but have additional requirements and limits that are less good >>>>>> fits for SDP. One of the >>>>>> >>>>>> The current assumption we have been working from, as detailed in >>>>>> draft-kyzivat-clue-signaling, is that the encodings (defined in >>>>>> draft-ietf-clue-framework), will be expressed in SDP and not in the >>>>>> CLUE signalling. However, this has only ever been a working >>>>>> assumption rather than something we've reached consensus on, and this >>>>>> is a fundamental design decision that impacts not just the message >>>>>> syntax but also the call flows and state machines inherent in the >>>>>> signalling. As such, I volunteered to examine the alternative >>>>>> approach, to hopefully allow us to resolve this issue so we can move >>>> forward. >>>>>> >>>>>> To do this I am going to examine two alternate options (for deails of >>>>>> the SDP approach see draft-kyzivat-clue-signaling). One is to, where >>>>>> possible, negotiate the limits and use of multiple video and audio >>>>>> subsessions as part of the CLUE Advertisment/Configure exchange, with >>>>>> the negotiated SDP m-lines treated as an 'envelope' subdivided by >>>>>> CLUE; this approach was the one that had more initial exploration by >>>>>> the CLUE WG before we moved towards the SDP approach. The other >>>>>> approach is a half-way house that has not yet been explored in any >>>>>> detail; this is to negotiate each channel in SDP, but to express the >>>>>> encoding constraints within the CLUE signalling. >>>>>> >>>>>> *** Encodings in CLUE *** >>>>>> >>>>>> In this approach the encodings available, and the constraints >>>>>> associated with them, are expressed in the CLUE Advertisment. The far >>>>>> end then selects which encodings they wish to receive, and the limits >>>>>> on those encodings as part of the CLUE Configure message. >>>>>> >>>>>> In the simplest (and, most likely, commonest case) this would allow a >>>>>> single sendrecv m-line per media type to be used for all sent and >>>>>> received CLUE-controlled streams. The various streams must then be >>>>>> demultiplexed; this can be done via explicit SSRC for static streams >>>>>> or via an additional header such as appId. SSRC is used in examples; >>>>>> replacing these with appId indicators should be roughly equivalent >>>>>> for streams with dynamic SSRCs. As such the initial SDP, and then >>>>>> Advertiment, might look something like: >>>>>> >>>>>> EXAMPLE SDP OFFER (from A) >>>>>> m=video ... >>>>>> ... >>>>>> a=ssrc:1234 >>>>>> a=ssrc:2345 >>>>>> a=ssrc:3456 >>>>>> a=sendrecv >>>>>> >>>>>> EXAMPLE ADVERTISMENT (from A) >>>>>> Capture Scene 1: >>>>>> Capture 1: Left (Encoding Group 1) >>>>>> Capture 2: Center (Encoding Group 1) >>>>>> Capture 3: Right (Encoding Group 1) >>>>>> Capture 4: Switched >>>>>> Capture Scene Entry 1: 1,2,3 >>>>>> Capture Scene Entry 2: 4 >>>>>> Simultaneous Sets: 1,2,3,4 >>>>>> Encoding Group 1: >>>>>> Encoding 1: H264, 1080p30, ssrc=1234 >>>>>> Encoding 2: H264, 1080p30, ssrc=2345 >>>>>> Encoding 3: H264, 1080p30, ssrc=3456 >>>>>> >>>>>> The SSRC/appId attributes are ignorable and hence sendable in the >>>>>> initial SSRC, though implementations may prefer to leave them out >>>>>> initially and then readvertise once CLUE is established. >>>>>> >>>>>> I've also included SSRCs alongside the encodings. In this case all >>>>>> encodings are on the same m-line, but there are scenarios where this >>>>>> multiplexing may not be appropriate or even possible, such as the >>>>>> disaggregated case when different streams must be sent to different >>>>>> IP addresses. In such circumstances there is a need to be able to >>>>>> distinguish which encodings can be sent on which m-line. An >>>>>> alternative would be to have the SSRCs only in SDP, and use something >>>>>> else to tie that to the encodings (such as a label attribute). >>>>>> >>>>>> Having the encodings split across multiple m-lines will present >>>>>> additional challenges, which will be detailed later. For now, >>>>>> consider the rest of the simple case. The far end will complete the >>>>>> SDP negotiation, and send a Configure message choosing what to >>>>>> receive, something like this: >>>>>> >>>>>> EXAMPLE SDP ANSWER (from B) >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> >>>>>> EXAMPLE CONFIGURATION (from B) >>>>>> Capture 1, Encoding 1 >>>>>> Capture 2, Encoding 2 >>>>>> Capture 3, Encoding 3 >>>>>> >>>>>> At this point the sender can begin sending three media streams, which >>>>>> the receiver can demultiplex by SSRC. >>>>>> >>>>>> However, one major issue remains even for the multiplexed case: how >>>>>> to express receiver encode limitations. These are currently expressed >>>>>> in SDP, and are defined to apply to a single media stream. However, >>>>>> in the case above three streams are being sent to that port, and we >>>>>> have to decide what those limits mean. >>>>>> >>>>>> One answer would be that it provides the *overall* limit, but this >>>>>> quickly runs into problems. One issue is that not all parameters can >>>>>> be sensibly subdivided: for H264 max-br and max-mbps could be divided >>>>>> into three relatively easily, but max-fs makes less sense. And even >>>>>> avoiding this, it would allow the far end to validly send a single >>>>>> stream that matched the combined limit, which the receiver might not >>>>>> be able to cope with; existing 3-screen systems often have three >>>>>> seperate decoders that cannot pool their decode resource (eg, they >>>>>> might be able to decode three 720p streams, but not one 1080p >>>>>> stream). >>>>>> >>>>>> As such a better answer is that the SDP receive limits express the >>>>>> limit for *any* individual stream; in the example above each of the >>>>>> three streams could be sent at up to 720p30. However, this still >>>>>> poses an >>>>>> issue: what happens if the receiver wants to receive different >>>>>> capture encodings with different constraints. In the example above >>>>>> most receivers will probably want all three streams at similar >>>>>> resolutions, but in the scenario where a device wants to receive one >>>>>> primary capture encoding to view full-screne and six >>>>>> capture-encodings to use as small picture-in-picture insets then the >>>>>> receiver needs to be able to express these different constraints. >>>>>> >>>>>> One option is for the SDP codec limit to provide a set of maxima for >>>>>> any given stream, but then be able to express *additional* limits for >>>>>> each capture encoding as part of the Configure message; a highly >>>>>> simplified version might look like this: >>>>>> >>>>>> EXAMPLE CONFIGURATION (from B) >>>>>> Capture 1, Encoding 1, 720p30 >>>>>> Capture 2, Encoding 2, 360p30 >>>>>> Capture 3, Encoding 3, 360p30 >>>>>> >>>>>> These would provide additional constraints on what could be sent for >>>>>> each stream; they could only lower (not raise) the constraints >>>>>> expressed in SDP. On the plus side, the 'encodings in CLUE' approach >>>>>> will mean we need to create syntax to express codec-specific encoder >>>>>> limitations for the Advertise messages, and much of that syntax could >>>>>> use here. On the minus side, this means replicating functionality >>>>>> that is already part of SDP. >>>>>> >>>>>> If we don't want to go down the route of re-expressing codec limits >>>>>> in CLUE there is another option, which is that receivers that want to >>>>>> express different receive limits for different capture encodings they >>>>>> wish to receive will need to create new m-lines in the SDP so they >>>>>> can differentiate between the capture encodings they want to receive. >>>>>> The plus side of this approach is that this is a requirement of the >>>>>> 'Encodings in CLUE' approach anyway, as it's needed for the case >>>>>> where the initial answerer is a disaggregated system that doesn't >>>>>> want to multiplex their streams; these scenarios will also need to >>>>>> reoffer with new m-lines and split up the streams. >>>>>> >>>>>> The downside of this approach is that coming up with a general way to >>>>>> mix and match multiple m-line each of which may multiplex different >>>>>> streams, and the ability to change the the number of m-lines in use >>>>>> and which encodings are multiplexed onto each is painful, to the >>>>>> point where I don't have a particularly good handle on it. I've >>>>>> included some initial speculation in an appendix at the end of the >>>>>> page to avoid eating up too much space here. >>>>>> >>>>>> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': >>>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>>> limitations using existing SDP syntax >>>>>> * In the straightforward multiplexed case fewer (or no) additional >>>>>> O/As and m-lines >>>>>> >>>>>> Disadvantages: >>>>>> * Need to reinvent syntax to express H264 (and any other codec) >>>>>> limitations >>>>>> * Problems with moving from multiplexed to non-multiplexed (and >>>>>> similar) >>>>>> * Media-specific information in CLUE messaging, potentially limiting >>>>>> interoperability with other ongoing multistream work >>>>>> >>>>>> *** Encoding Constraints in CLUE *** >>>>>> >>>>>> This scenario presents a half-way house between the 'Encodings in >>>>>> CLUE' >>>>>> approach expressed above and the 'Encodings in SDP' approach >>>>>> expressed in draft-kyzivat-clue-signaling. In this case there is a >>>>>> seperate m-line per stream, just as with the 'Encodings in SDP' >>>>>> approach. However, in this approach the encoding constraints are >>>>>> expressed in the CLUE Advertisment. >>>>>> >>>>>> Let us explore the three-screen example from before with this new >>>>>> approach. There will be an initial SDP O/A to establish the CLUE >>>>>> channel and verify that both sides support CLUE. There is then a new >>>>>> SDP offer with an m-line per stream available, and a matching >>>> advertisment: >>>>>> >>>>>> EXAMPLE SDP OFFER (from A) >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=label:A >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=label:B >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=label:C >>>>>> a=sendrecv >>>>>> >>>>>> EXAMPLE ADVERTISMENT (from A) >>>>>> Capture Scene 1: >>>>>> Capture 1: Left (Encoding Group 1) >>>>>> Capture 2: Center (Encoding Group 1) >>>>>> Capture 3: Right (Encoding Group 1) >>>>>> Capture 4: Switched >>>>>> Capture Scene Entry 1: 1,2,3 >>>>>> Capture Scene Entry 2: 4 >>>>>> Simultaneous Sets: 1,2,3,4 >>>>>> Encoding Group 1: >>>>>> Encoding 1: H264, 1080p30, label=A >>>>>> Encoding 2: H264, 1080p30, label=B >>>>>> Encoding 3: H264, 1080p30, label=C >>>>>> >>>>>> I've used label above to tie the encodings to the m-lines, but this >>>>>> could alternately be SSRC (if SSRC was being used), appId (if appId >>>>>> were being used) or anything else. >>>>>> >>>>>> This closely matches the examples in draft-kyzivat-clue-signaling. >>>>>> However, the sender can use 'sendrecv' rather than 'sendonly' for the >>>>>> new m-lines rather than 'sendonly', as the encoder limits are >>>>>> expressed instead in CLUE. This also has the advantage that the CLUE >>>>>> syntax for these limits allows the precise H264 send limits to be >>>>>> expressed (while SDP limits which parameters can be used in H.264 >>>> sendonly). >>>>>> >>>>>> If the far end wants to receive the three static captures then it >>>>>> sends an answer SDP which can accept those, along with a Configure >>>>>> message specifying which captures it wants to receive: >>>>>> >>>>>> EXAMPLE SDP ANSWER (from B) >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> >>>>>> EXAMPLE CONFIGURATION (from B) >>>>>> Capture 1, Encoding 1 >>>>>> Capture 2, Encoding 2 >>>>>> Capture 3, Encoding 3 >>>>>> >>>>>> The receiver no longer needs to express the receive limits in CLUE; >>>>>> with an m-line per received stream the standard SDP parameters >>>>>> already allow full expression of the limitations. Now it just needs >>>>>> to state what encoding it wants to use for each capture it receives. >>>>>> >>>>>> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we >>>>>> consider the other direction (B sendings to A) then if B has three >>>>>> streams or fewer then it will not have to make a new SDP offer. For >>>>>> instance, if B supported up to two encodings its response could >>>>>> instead have been: >>>>>> >>>>>> EXAMPLE SDP ANSWER (from B) >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... H264@720p30 >>>>>> a=recvonly >>>>>> >>>>>> And could immediately send an Advertisment with its capture and >>>>>> encoding information. A new offer would be needed if B had more >>>>>> encodings than A, or if A wanted to change its receive capabilities >>>>>> based on the capture encodings it wanted from A. >>>>>> >>>>>> This approach is very like the 'Encodings in SDP' approach, with the >>>>>> following advantages and disadvantages: >>>>>> >>>>>> Advantages relative to 'Encodings in SDP': >>>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>>> limitations using existing SDP syntax >>>>>> * Many m-lines can be sendrecv, in many cases will need fewer O/As >>>>>> >>>>>> Disadvantages: >>>>>> * Still need to reinvent syntax to express H264 (and any other codec) >>>>>> encoding limitations >>>>>> >>>>>> *** Summary *** >>>>>> >>>>>> Appealing as the 'Encodings in CLUE' case is when all streams of a >>>>>> given media type can be multiplexed onto a single m-line, treating >>>>>> SDP as an 'envelope' CLUe can subdivide, I don't believe this >>>>>> approach is actually feasible. Also having to support the multiple >>>>>> m-line case and be able to sensibly change the number of m-lines is >>>>>> painful, while the need to replicate receive codec limits in CLUE >>>>>> that are already expressed very capably in SDP is unlikely to be >>> popular. >>>>>> >>>>>> I believe the 'Encoding *constraints* in CLUE' approach is >>>>>> considerably more plausible, though the variation from the 'Encodings >>> in >>>> SDP' >>>>>> approach is fairly small. Principly it comes down to whether the work >>>>>> required to develop syntax to express the send limits for the various >>>>>> codecs in CLUE is worth the added accuracy of what can be expressed >>>>>> in CLUE over what is currently available in SDP, along with the >>>>>> advantage of less need to add new m-lines (and the associated O/As >>>> involved). >>>>>> >>>>>> *** Appendix *** >>>>>> >>>>>> Let us first consider the case of wanting to split an offered set of >>>>>> streams. The sender (A) can send up to five capture encodings, and so >>>>>> send an SDP offer along the lines of: >>>>>> >>>>>> m=video ... >>>>>> ... >>>>>> a=ssrc:1234 >>>>>> a=ssrc:2345 >>>>>> a=ssrc:3456 >>>>>> a=ssrc:4567 >>>>>> a=ssrc:5678 >>>>>> a=sendrecv >>>>>> >>>>>> The receiver (B) wants to receive one of those streams on one m-line, >>>>>> three more on a second m-line and the fifth not at all. The rules of >>>>>> O/A mean that B must send an initial answer with the single m-line, >>>>>> which we won't illustrate here, and then send a new offer. Some >>>>>> method must be provided to show what streams are to be received >>>>>> where; in this case I'm using the max-ssrc draft: >>>>>> >>>>>> m=video ... >>>>>> ... >>>>>> a=max-recv-ssrc:{*:1} >>>>>> a=sendrecv >>>>>> m=video ... >>>>>> ... >>>>>> a=max-recv-ssrc:{*:3} >>>>>> a=sendrecv >>>>>> m=video ... 0 >>>>>> >>>>>> A will then need to reorder their allocation of SSRCs to m-lines to >>>>>> sensibly fit this. And if later in the call B decides that it now >>>>>> wants to multiplex all of the streams this will need to be done in >>>>>> reverse, with B sending a new offer with only one activevideo m-line >>>>>> and suitable max-recv-ssrc value and hope that A will correctly >>>>>> interpret this. This reallocation of streams between m-lines is the >>>>>> part I think will be difficult to define normatively. >>>>>> >>>>>> Rob >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Sat Oct 12 11:35:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DEB21E81B9 for ; Sat, 12 Oct 2013 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHNS1UhnMd4f for ; Sat, 12 Oct 2013 11:35:56 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDB321E81BF for ; Sat, 12 Oct 2013 11:35:36 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id ii20so1502370qab.10 for ; Sat, 12 Oct 2013 11:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=NI2HOYGf1HmSyFgbJyeWMzj3LOVAfRo/VZK+ZqBBR5g=; b=BXeUEOBbJkRnvEZPMPd2Z6sgn2nYZkjaY4YomvnurrixT0lm9Zt44TudIPBwr8Vc8p f5lhE6fJ2bebja2ZQHRYYDgzotlIlC2JDF13VQAY4IZq/felRohKb7/KhgToz7xVpOgq yHILBLWFMmCdYUbLHDtqnBGXE1VOkJ13NZtgghL/qlV5sFd7YLphjByiTqjUA4VQTynP bPFWlfxe8oJUo/ko/A6HYlr+9Vdmzso9aOuWnnBtQpAnWICMh4Y288QPUhyhsB0PAwKU sLM7r0lV5/rH/LbwBXqRgc+2Ht//PxY7G72kZMQ3cX2VGF0C1xGlq6oQLQmCbUx8SCmM nWxQ== MIME-Version: 1.0 X-Received: by 10.229.244.69 with SMTP id lp5mr27588386qcb.14.1381602935637; Sat, 12 Oct 2013 11:35:35 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Sat, 12 Oct 2013 11:35:35 -0700 (PDT) Date: Sat, 12 Oct 2013 13:35:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c2c54c330ea404e88f80fc Subject: [clue] CLUE WG sessions @ IETF-88 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 18:35:57 -0000 --001a11c2c54c330ea404e88f80fc Content-Type: text/plain; charset=ISO-8859-1 The "final" agenda has been published: https://datatracker.ietf.org/meeting/88/agenda.txt We have two CLUE sessions scheduled: Tuesday: 9:00-11:30 Friday: 11:20-13:30 (this takes two one hour slots & we'll be working straight through the 10 min break between the two slots) We will post a preliminary agenda no later than Wednesday, Oct. 23rd. Of course, the agenda will be based on recent WG discussions, as well as any outcomes from the recent design team meeting. Folks might find it very helpful to review the notes from those meetings and even listen to some of the recordings. We will be focusing the majority of time on the solution space. As a reminder, the draft deadline is in just over a weeks time: Monday, October 14th by 24:00 UTC Regards, Mary --001a11c2c54c330ea404e88f80fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      The "final" agenda has been published:

      We have = two CLUE sessions scheduled:
      Tuesday: 9:00-11:30
      Friday: 11:20-13:30 (this takes two one = hour slots & we'll be working straight through the 10 min break bet= ween the two slots)

      We will post a preliminary age= nda no later than Wednesday, Oct. 23rd.=A0
      Of course, the agenda will be based on recent WG discussions, as well = as any outcomes from the recent design team meeting. =A0Folks might find it= very helpful to review the notes from those meetings and even listen to so= me of the recordings. =A0We will be focusing the majority of time on the so= lution space.

      As a reminder, the draft deadline is in just over a wee= ks time: =A0
      Monday, October 14th by 24:00 UTC

      Regards,
      Mary
      --001a11c2c54c330ea404e88f80fc-- From Christian.Groves@nteczone.com Sun Oct 13 19:44:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68A21F9D0E for ; Sun, 13 Oct 2013 19:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[AWL=-2.344, BAYES_40=-0.185, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qXjaRFXU1VS for ; Sun, 13 Oct 2013 19:44:15 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id C118621F90A7 for ; Sun, 13 Oct 2013 19:44:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJNZW1J20brS/2dsb2JhbAANTIM/wjAJgTCDGQEBAQQBAQEXHhsbBAYNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQEXh3eqE5J3BI4JC4E5DAaEHQOiU4psgVMBBAIC Received: from ppp118-209-186-210.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.186.210]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Oct 2013 13:14:05 +1030 Message-ID: <525B5A73.4070800@nteczone.com> Date: Mon, 14 Oct 2013 13:44:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <5253C3C5.6080207@cisco.com> <52544BB9.7060403@cisco.com> <525578E9.6010500@alum.mit.edu> <009901cec511$73984d00$5ac8e700$@gmail.com> <5255AD6F.8070302@alum.mit.edu> <52574E9E.6000701@nteczone.com> <52584FB0.5060507@alum.mit.edu> In-Reply-To: <52584FB0.5060507@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Expressing encoding information in CLUE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 02:44:17 -0000 Hello Paul, My understanding is that 3GPP uses the media capability negotiation framework (i.e. 3GPP TS 24.292). However I'm not sure if they utilise latent configurations. With respect to the usage of label the examples do show the use of label with configurations with respect to the BFCP protocol. So I couldn't see why it wouldn't be valid to use label for CLUE? I don't see we would be breaking any new ground. Regards, Christian On 12/10/2013 6:21 AM, Paul Kyzivat wrote: > Christian, > > I had given passing thought to capneg, but no more than that. Its > worth discussing. (Note that I don't know much about it.) > > I have yet to hear of anyone actually using this mechanism. Presumably > somebody has. But IMO it remains to be seen if this is going to fly. > If somebody can cite deployments that could ease my concerns. > > If we went that way, then we would have need to reference parts of a > latent configuration from the CLUE protocol. I think we would be > breaking new ground there. Its highly questionable whether reference > to a=label attributes embedded within a latent configuration are well > defined. That may be true of references to latent a=mid attributes as > well. > > (In fact, attempting to use the grouping framework within a latent > configuration might present difficulties.) > > This doesn't mean we can't make this work. It does mean its going to > take some effort to do so. > > Thanks, > Paul > > On 10/10/13 9:04 PM, Christian Groves wrote: >> With regards to not allocating resources isn't that what RFC 6871 and >> the latent configuration attribute is for? i.e. >> >> Latent Configuration: A latent configuration indicates which >> combinations of capabilities could be used in a future negotiation >> for the session and its associated media stream components. Latent >> configurations are neither ready for use nor offered for actual or >> potential use in the current offer/answer exchange. Latent >> configurations merely inform the other side of possible >> configurations supported by the entity. Those latent configurations >> may be used to guide subsequent offer/answer exchanges, but they are >> not offered for use as part of the current offer/answer exchange >> >> >> An Advertiser could offer the "base" audio and video and then the extra >> captures as latent configurations. The latent configurations can then be >> linked the CLUE capture through a=label etc. >> >> RFC7006 also allows a means of indicating the bandwidth capabilities. >> This could also be used instead of having CLUE provide this. >> >> Regards, >> Christian >> >> >> On 10/10/2013 6:24 AM, Paul Kyzivat wrote: >>> On 10/9/13 1:03 PM, Roni Even wrote: >>>> Hi, >>>> Some quick points, I still need to look more into the options and I >>>> was busy >>>> this week and could not attend the Tuesday call. >>>> >>>> As for Paul concern about the resource allocation when providing the >>>> encoding is SDP , I think that this is not an issue since the m-lines >>>> specify sendonly streams to be used by the advertisement (section 6 >>>> examples >>>> of the signaling draft) >>> >>> My understanding of how when/how the bandwidth is managed is pretty >>> fuzzy. But it would be nice if it isn't a problem in this case. >>> >>> Reserving ports, ICE, etc. is still an issue, but bundle will help >>> with that. >>> >>> Thanks, >>> Paul >>> >>>> My general view on the encoding was not favorable from the start. I >>>> could >>>> not understand why we need the resource management as part of CLUE. >>>> My past >>>> experience was that trying to optimize resource per each codec is not >>>> easy >>>> and it is better to use abstract compute units that are codec >>>> independent >>>> but allow for multiplications of the unit based on capabilities. For >>>> example >>>> H.264 CIF will be one unit and H.264 HD will use 4 units and VP8 HD >>>> will use >>>> 4 units (not real numbers just an example), still I am not sure why >>>> in CLUE >>>> where we wanted to address relations between streams (spatial) we >>>> invest so >>>> much in resource management. >>>> >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of >>>>> Paul Kyzivat >>>>> Sent: 09 October, 2013 6:40 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Expressing encoding information in CLUE >>>>> >>>>> Rob, >>>>> >>>>> Thanks for digging into this and getting the discussion started. >>>>> This is an important decision, so we need some vigorous >>>>> discussion. I'm >>>>> looking for feedback from everybody that is actively involved in >>>>> this. >>>>> >>>>> I've been on both sides of this. I've pursued the encoding-in-SDP >>>>> approach >>>> in >>>>> the signaling document. In part because of the consequences that >>>>> showed >>>>> up in doing that I've been pushing the exploration of the >>>>> alternative(s). >>>> Now >>>>> we have that. >>>>> >>>>> With the encoding-in-SDP approach I remain disturbed by the need for >>>>> the >>>>> advertiser to commit media resources (ports, bandwidth) for all the >>>>> encodings it wants to mention in an advertisement. I think this >>>>> could be >>>> quite >>>>> burdensome, especially for an MCU, that may be advertising many more >>>>> options than any one endpoint is likely to use. This will be less >>>>> of a >>>> problem >>>>> with bundling, but it still may be a burden wrt bandwidth >>>>> commitments. It >>>>> would be unfortunate if the MCU must limit itself in the number of >>>>> encodings it offers to avoid the call being blocked for demanding >>>>> too much >>>>> bandwidth. >>>>> >>>>> OTOH, I appreciate Rob's concern over reinventing syntax for codec >>>> specific >>>>> constraints. >>>>> >>>>> There is no perfect answer here - we must pick our poison. >>>>> >>>>> I'm not going to make a choice of my own now (maybe ever). I want to >>>>> see >>>>> what others say. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 10/8/13 2:15 PM, Robert Hansen wrote: >>>>>> The previous was an attempt at a relatively objective look at the >>>>>> different syntactic options for conveying encoding information in >>>>>> CLUE. >>>>>> However, I do have opinions on the options available. >>>>>> >>>>>> The proposal for negotiating both encodings and multiplexing >>>>>> behaviour >>>>>> in CLUE was included because it's something we have discussed >>>>>> heavily >>>>>> in the past. However there were good reason we moved away from it >>>>>> - it >>>>>> provides a CLUE-specific method of multiplexing that won't play well >>>>>> with the syntax being defined in the wider MMUSIC sphere, as well as >>>>>> all the problems inhereit with multiplexing on a single m-line. >>>>>> >>>>>> The other two options explored use SDP for multiplexing, but one >>>>>> expressed the encoding limitations in SDP while the other does so in >>>>>> CLUE. I think both are workable solutions, but my preference is for >>>>>> the SDP option. >>>>>> >>>>>> While the expressing encoding limitations in CLUE approach does >>>>>> provide a number of advantages: fewer m-lines, fewer O/As, more >>>>>> accurate encoder limitations and (as Paul pointed out in the design >>>>>> call today) the ability to express encoder limitations without >>>>>> committing resources, I think the need to come up with syntax for >>>>>> the >>>>>> encoding limits in CLUE is a painful one. If these limits can be >>>>>> expressed in abstract, codec-independent ways then that's one thing, >>>>>> but each time this issue comes up somewhere the upshot seems to be >>>>>> that abstract, codec-independent limitations aren't actually >>>>>> possible, >>>>>> and that would leave us with the need to reinvent syntax for any >>>>>> codec >>>>> that could be used. >>>>>> >>>>>> I'd be very happy to be proved wrong about this, but I don't >>>>>> think the >>>>>> advantages of expressing the encoding constraints in CLUE are >>>>>> sufficient to outweight the cost of such codec-specific work, and I >>>>>> don't think we'll be able to come up with a nice abstraction >>>>>> everyone >>>> will >>>>> sign off on. >>>>>> >>>>>> Rob >>>>>> >>>>>> On 08/10/2013 09:35, Robert Hansen wrote: >>>>>>> At the design meeting last week I volunteered to take a stab at >>>>>>> evaluating alternate approaches to conveying all encoding >>>>>>> information >>>>>>> in SDP. The text got a bit long for an email, so I've also attached >>>>>>> it as a text document. I'll also put together some slides on the >>>>>>> topic for this call this afternoon. >>>>>>> >>>>>>> One of the fundamental issues we have in clue is how to >>>>>>> negotiate the >>>>>>> details of the encodings defined in draft-ietf-clue-framework. >>>>>>> Unless >>>>>>> other entities such as captures, which are unique to CLUE, >>>>>>> encodings >>>>>>> share many properties with limits that are currently expressible in >>>>>>> SDP, but have additional requirements and limits that are less good >>>>>>> fits for SDP. One of the >>>>>>> >>>>>>> The current assumption we have been working from, as detailed in >>>>>>> draft-kyzivat-clue-signaling, is that the encodings (defined in >>>>>>> draft-ietf-clue-framework), will be expressed in SDP and not in the >>>>>>> CLUE signalling. However, this has only ever been a working >>>>>>> assumption rather than something we've reached consensus on, and >>>>>>> this >>>>>>> is a fundamental design decision that impacts not just the message >>>>>>> syntax but also the call flows and state machines inherent in the >>>>>>> signalling. As such, I volunteered to examine the alternative >>>>>>> approach, to hopefully allow us to resolve this issue so we can >>>>>>> move >>>>> forward. >>>>>>> >>>>>>> To do this I am going to examine two alternate options (for >>>>>>> deails of >>>>>>> the SDP approach see draft-kyzivat-clue-signaling). One is to, >>>>>>> where >>>>>>> possible, negotiate the limits and use of multiple video and audio >>>>>>> subsessions as part of the CLUE Advertisment/Configure exchange, >>>>>>> with >>>>>>> the negotiated SDP m-lines treated as an 'envelope' subdivided by >>>>>>> CLUE; this approach was the one that had more initial >>>>>>> exploration by >>>>>>> the CLUE WG before we moved towards the SDP approach. The other >>>>>>> approach is a half-way house that has not yet been explored in any >>>>>>> detail; this is to negotiate each channel in SDP, but to express >>>>>>> the >>>>>>> encoding constraints within the CLUE signalling. >>>>>>> >>>>>>> *** Encodings in CLUE *** >>>>>>> >>>>>>> In this approach the encodings available, and the constraints >>>>>>> associated with them, are expressed in the CLUE Advertisment. >>>>>>> The far >>>>>>> end then selects which encodings they wish to receive, and the >>>>>>> limits >>>>>>> on those encodings as part of the CLUE Configure message. >>>>>>> >>>>>>> In the simplest (and, most likely, commonest case) this would >>>>>>> allow a >>>>>>> single sendrecv m-line per media type to be used for all sent and >>>>>>> received CLUE-controlled streams. The various streams must then be >>>>>>> demultiplexed; this can be done via explicit SSRC for static >>>>>>> streams >>>>>>> or via an additional header such as appId. SSRC is used in >>>>>>> examples; >>>>>>> replacing these with appId indicators should be roughly equivalent >>>>>>> for streams with dynamic SSRCs. As such the initial SDP, and then >>>>>>> Advertiment, might look something like: >>>>>>> >>>>>>> EXAMPLE SDP OFFER (from A) >>>>>>> m=video ... >>>>>>> ... >>>>>>> a=ssrc:1234 >>>>>>> a=ssrc:2345 >>>>>>> a=ssrc:3456 >>>>>>> a=sendrecv >>>>>>> >>>>>>> EXAMPLE ADVERTISMENT (from A) >>>>>>> Capture Scene 1: >>>>>>> Capture 1: Left (Encoding Group 1) >>>>>>> Capture 2: Center (Encoding Group 1) >>>>>>> Capture 3: Right (Encoding Group 1) >>>>>>> Capture 4: Switched >>>>>>> Capture Scene Entry 1: 1,2,3 >>>>>>> Capture Scene Entry 2: 4 >>>>>>> Simultaneous Sets: 1,2,3,4 >>>>>>> Encoding Group 1: >>>>>>> Encoding 1: H264, 1080p30, ssrc=1234 >>>>>>> Encoding 2: H264, 1080p30, ssrc=2345 >>>>>>> Encoding 3: H264, 1080p30, ssrc=3456 >>>>>>> >>>>>>> The SSRC/appId attributes are ignorable and hence sendable in the >>>>>>> initial SSRC, though implementations may prefer to leave them out >>>>>>> initially and then readvertise once CLUE is established. >>>>>>> >>>>>>> I've also included SSRCs alongside the encodings. In this case all >>>>>>> encodings are on the same m-line, but there are scenarios where >>>>>>> this >>>>>>> multiplexing may not be appropriate or even possible, such as the >>>>>>> disaggregated case when different streams must be sent to different >>>>>>> IP addresses. In such circumstances there is a need to be able to >>>>>>> distinguish which encodings can be sent on which m-line. An >>>>>>> alternative would be to have the SSRCs only in SDP, and use >>>>>>> something >>>>>>> else to tie that to the encodings (such as a label attribute). >>>>>>> >>>>>>> Having the encodings split across multiple m-lines will present >>>>>>> additional challenges, which will be detailed later. For now, >>>>>>> consider the rest of the simple case. The far end will complete the >>>>>>> SDP negotiation, and send a Configure message choosing what to >>>>>>> receive, something like this: >>>>>>> >>>>>>> EXAMPLE SDP ANSWER (from B) >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> >>>>>>> EXAMPLE CONFIGURATION (from B) >>>>>>> Capture 1, Encoding 1 >>>>>>> Capture 2, Encoding 2 >>>>>>> Capture 3, Encoding 3 >>>>>>> >>>>>>> At this point the sender can begin sending three media streams, >>>>>>> which >>>>>>> the receiver can demultiplex by SSRC. >>>>>>> >>>>>>> However, one major issue remains even for the multiplexed case: how >>>>>>> to express receiver encode limitations. These are currently >>>>>>> expressed >>>>>>> in SDP, and are defined to apply to a single media stream. However, >>>>>>> in the case above three streams are being sent to that port, and we >>>>>>> have to decide what those limits mean. >>>>>>> >>>>>>> One answer would be that it provides the *overall* limit, but this >>>>>>> quickly runs into problems. One issue is that not all parameters >>>>>>> can >>>>>>> be sensibly subdivided: for H264 max-br and max-mbps could be >>>>>>> divided >>>>>>> into three relatively easily, but max-fs makes less sense. And even >>>>>>> avoiding this, it would allow the far end to validly send a single >>>>>>> stream that matched the combined limit, which the receiver might >>>>>>> not >>>>>>> be able to cope with; existing 3-screen systems often have three >>>>>>> seperate decoders that cannot pool their decode resource (eg, they >>>>>>> might be able to decode three 720p streams, but not one 1080p >>>>>>> stream). >>>>>>> >>>>>>> As such a better answer is that the SDP receive limits express the >>>>>>> limit for *any* individual stream; in the example above each of the >>>>>>> three streams could be sent at up to 720p30. However, this still >>>>>>> poses an >>>>>>> issue: what happens if the receiver wants to receive different >>>>>>> capture encodings with different constraints. In the example above >>>>>>> most receivers will probably want all three streams at similar >>>>>>> resolutions, but in the scenario where a device wants to receive >>>>>>> one >>>>>>> primary capture encoding to view full-screne and six >>>>>>> capture-encodings to use as small picture-in-picture insets then >>>>>>> the >>>>>>> receiver needs to be able to express these different constraints. >>>>>>> >>>>>>> One option is for the SDP codec limit to provide a set of maxima >>>>>>> for >>>>>>> any given stream, but then be able to express *additional* >>>>>>> limits for >>>>>>> each capture encoding as part of the Configure message; a highly >>>>>>> simplified version might look like this: >>>>>>> >>>>>>> EXAMPLE CONFIGURATION (from B) >>>>>>> Capture 1, Encoding 1, 720p30 >>>>>>> Capture 2, Encoding 2, 360p30 >>>>>>> Capture 3, Encoding 3, 360p30 >>>>>>> >>>>>>> These would provide additional constraints on what could be sent >>>>>>> for >>>>>>> each stream; they could only lower (not raise) the constraints >>>>>>> expressed in SDP. On the plus side, the 'encodings in CLUE' >>>>>>> approach >>>>>>> will mean we need to create syntax to express codec-specific >>>>>>> encoder >>>>>>> limitations for the Advertise messages, and much of that syntax >>>>>>> could >>>>>>> use here. On the minus side, this means replicating functionality >>>>>>> that is already part of SDP. >>>>>>> >>>>>>> If we don't want to go down the route of re-expressing codec limits >>>>>>> in CLUE there is another option, which is that receivers that >>>>>>> want to >>>>>>> express different receive limits for different capture encodings >>>>>>> they >>>>>>> wish to receive will need to create new m-lines in the SDP so they >>>>>>> can differentiate between the capture encodings they want to >>>>>>> receive. >>>>>>> The plus side of this approach is that this is a requirement of the >>>>>>> 'Encodings in CLUE' approach anyway, as it's needed for the case >>>>>>> where the initial answerer is a disaggregated system that doesn't >>>>>>> want to multiplex their streams; these scenarios will also need to >>>>>>> reoffer with new m-lines and split up the streams. >>>>>>> >>>>>>> The downside of this approach is that coming up with a general >>>>>>> way to >>>>>>> mix and match multiple m-line each of which may multiplex different >>>>>>> streams, and the ability to change the the number of m-lines in use >>>>>>> and which encodings are multiplexed onto each is painful, to the >>>>>>> point where I don't have a particularly good handle on it. I've >>>>>>> included some initial speculation in an appendix at the end of the >>>>>>> page to avoid eating up too much space here. >>>>>>> >>>>>>> Advantages of 'Encodings in CLUE' relative to 'Encodings in SDP': >>>>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>>>> limitations using existing SDP syntax >>>>>>> * In the straightforward multiplexed case fewer (or no) additional >>>>>>> O/As and m-lines >>>>>>> >>>>>>> Disadvantages: >>>>>>> * Need to reinvent syntax to express H264 (and any other codec) >>>>>>> limitations >>>>>>> * Problems with moving from multiplexed to non-multiplexed (and >>>>>>> similar) >>>>>>> * Media-specific information in CLUE messaging, potentially >>>>>>> limiting >>>>>>> interoperability with other ongoing multistream work >>>>>>> >>>>>>> *** Encoding Constraints in CLUE *** >>>>>>> >>>>>>> This scenario presents a half-way house between the 'Encodings in >>>>>>> CLUE' >>>>>>> approach expressed above and the 'Encodings in SDP' approach >>>>>>> expressed in draft-kyzivat-clue-signaling. In this case there is a >>>>>>> seperate m-line per stream, just as with the 'Encodings in SDP' >>>>>>> approach. However, in this approach the encoding constraints are >>>>>>> expressed in the CLUE Advertisment. >>>>>>> >>>>>>> Let us explore the three-screen example from before with this new >>>>>>> approach. There will be an initial SDP O/A to establish the CLUE >>>>>>> channel and verify that both sides support CLUE. There is then a >>>>>>> new >>>>>>> SDP offer with an m-line per stream available, and a matching >>>>> advertisment: >>>>>>> >>>>>>> EXAMPLE SDP OFFER (from A) >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=label:A >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=label:B >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=label:C >>>>>>> a=sendrecv >>>>>>> >>>>>>> EXAMPLE ADVERTISMENT (from A) >>>>>>> Capture Scene 1: >>>>>>> Capture 1: Left (Encoding Group 1) >>>>>>> Capture 2: Center (Encoding Group 1) >>>>>>> Capture 3: Right (Encoding Group 1) >>>>>>> Capture 4: Switched >>>>>>> Capture Scene Entry 1: 1,2,3 >>>>>>> Capture Scene Entry 2: 4 >>>>>>> Simultaneous Sets: 1,2,3,4 >>>>>>> Encoding Group 1: >>>>>>> Encoding 1: H264, 1080p30, label=A >>>>>>> Encoding 2: H264, 1080p30, label=B >>>>>>> Encoding 3: H264, 1080p30, label=C >>>>>>> >>>>>>> I've used label above to tie the encodings to the m-lines, but this >>>>>>> could alternately be SSRC (if SSRC was being used), appId (if appId >>>>>>> were being used) or anything else. >>>>>>> >>>>>>> This closely matches the examples in draft-kyzivat-clue-signaling. >>>>>>> However, the sender can use 'sendrecv' rather than 'sendonly' >>>>>>> for the >>>>>>> new m-lines rather than 'sendonly', as the encoder limits are >>>>>>> expressed instead in CLUE. This also has the advantage that the >>>>>>> CLUE >>>>>>> syntax for these limits allows the precise H264 send limits to be >>>>>>> expressed (while SDP limits which parameters can be used in H.264 >>>>> sendonly). >>>>>>> >>>>>>> If the far end wants to receive the three static captures then it >>>>>>> sends an answer SDP which can accept those, along with a Configure >>>>>>> message specifying which captures it wants to receive: >>>>>>> >>>>>>> EXAMPLE SDP ANSWER (from B) >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> >>>>>>> EXAMPLE CONFIGURATION (from B) >>>>>>> Capture 1, Encoding 1 >>>>>>> Capture 2, Encoding 2 >>>>>>> Capture 3, Encoding 3 >>>>>>> >>>>>>> The receiver no longer needs to express the receive limits in CLUE; >>>>>>> with an m-line per received stream the standard SDP parameters >>>>>>> already allow full expression of the limitations. Now it just needs >>>>>>> to state what encoding it wants to use for each capture it >>>>>>> receives. >>>>>>> >>>>>>> Also, in the SDP the new m-lines are marked as 'sendrecv'; if we >>>>>>> consider the other direction (B sendings to A) then if B has three >>>>>>> streams or fewer then it will not have to make a new SDP offer. For >>>>>>> instance, if B supported up to two encodings its response could >>>>>>> instead have been: >>>>>>> >>>>>>> EXAMPLE SDP ANSWER (from B) >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... H264@720p30 >>>>>>> a=recvonly >>>>>>> >>>>>>> And could immediately send an Advertisment with its capture and >>>>>>> encoding information. A new offer would be needed if B had more >>>>>>> encodings than A, or if A wanted to change its receive capabilities >>>>>>> based on the capture encodings it wanted from A. >>>>>>> >>>>>>> This approach is very like the 'Encodings in SDP' approach, with >>>>>>> the >>>>>>> following advantages and disadvantages: >>>>>>> >>>>>>> Advantages relative to 'Encodings in SDP': >>>>>>> * 'Encodings in SDP' approach can't express all H.264 send >>>>>>> limitations using existing SDP syntax >>>>>>> * Many m-lines can be sendrecv, in many cases will need fewer O/As >>>>>>> >>>>>>> Disadvantages: >>>>>>> * Still need to reinvent syntax to express H264 (and any other >>>>>>> codec) >>>>>>> encoding limitations >>>>>>> >>>>>>> *** Summary *** >>>>>>> >>>>>>> Appealing as the 'Encodings in CLUE' case is when all streams of a >>>>>>> given media type can be multiplexed onto a single m-line, treating >>>>>>> SDP as an 'envelope' CLUe can subdivide, I don't believe this >>>>>>> approach is actually feasible. Also having to support the multiple >>>>>>> m-line case and be able to sensibly change the number of m-lines is >>>>>>> painful, while the need to replicate receive codec limits in CLUE >>>>>>> that are already expressed very capably in SDP is unlikely to be >>>> popular. >>>>>>> >>>>>>> I believe the 'Encoding *constraints* in CLUE' approach is >>>>>>> considerably more plausible, though the variation from the >>>>>>> 'Encodings >>>> in >>>>> SDP' >>>>>>> approach is fairly small. Principly it comes down to whether the >>>>>>> work >>>>>>> required to develop syntax to express the send limits for the >>>>>>> various >>>>>>> codecs in CLUE is worth the added accuracy of what can be expressed >>>>>>> in CLUE over what is currently available in SDP, along with the >>>>>>> advantage of less need to add new m-lines (and the associated O/As >>>>> involved). >>>>>>> >>>>>>> *** Appendix *** >>>>>>> >>>>>>> Let us first consider the case of wanting to split an offered >>>>>>> set of >>>>>>> streams. The sender (A) can send up to five capture encodings, >>>>>>> and so >>>>>>> send an SDP offer along the lines of: >>>>>>> >>>>>>> m=video ... >>>>>>> ... >>>>>>> a=ssrc:1234 >>>>>>> a=ssrc:2345 >>>>>>> a=ssrc:3456 >>>>>>> a=ssrc:4567 >>>>>>> a=ssrc:5678 >>>>>>> a=sendrecv >>>>>>> >>>>>>> The receiver (B) wants to receive one of those streams on one >>>>>>> m-line, >>>>>>> three more on a second m-line and the fifth not at all. The >>>>>>> rules of >>>>>>> O/A mean that B must send an initial answer with the single m-line, >>>>>>> which we won't illustrate here, and then send a new offer. Some >>>>>>> method must be provided to show what streams are to be received >>>>>>> where; in this case I'm using the max-ssrc draft: >>>>>>> >>>>>>> m=video ... >>>>>>> ... >>>>>>> a=max-recv-ssrc:{*:1} >>>>>>> a=sendrecv >>>>>>> m=video ... >>>>>>> ... >>>>>>> a=max-recv-ssrc:{*:3} >>>>>>> a=sendrecv >>>>>>> m=video ... 0 >>>>>>> >>>>>>> A will then need to reorder their allocation of SSRCs to m-lines to >>>>>>> sensibly fit this. And if later in the call B decides that it now >>>>>>> wants to multiplex all of the streams this will need to be done in >>>>>>> reverse, with B sending a new offer with only one activevideo >>>>>>> m-line >>>>>>> and suitable max-recv-ssrc value and hope that A will correctly >>>>>>> interpret this. This reallocation of streams between m-lines is the >>>>>>> part I think will be difficult to define normatively. >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Oct 13 20:05:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A702D11E81DB for ; Sun, 13 Oct 2013 20:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-ZaLD5VU3FZ for ; Sun, 13 Oct 2013 20:05:20 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id B460911E81D9 for ; Sun, 13 Oct 2013 20:05:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEBeW1J20brS/2dsb2JhbAANTIM/wjmBMIMZAQEBAwEBAQEvAQUbGwoGCwsYCRYPCQMCAQIBFTATBgIBAYd8EqockngEj1mEIwOtPw Received: from ppp118-209-186-210.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.186.210]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Oct 2013 13:35:17 +1030 Message-ID: <525B5F6A.1000506@nteczone.com> Date: Mon, 14 Oct 2013 14:05:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60379FF86@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60379FF86@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] redefining scene-switch-policy? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 03:05:23 -0000 Hello Mark, Please see my comments below. Regards, Christian On 12/10/2013 2:28 AM, Duckworth, Mark wrote: > > Christian, Roni, Weiwei, > > draft-groves-clue-multi-content-00 section 3.3.3 has a proposal for > renaming the scene-switch-policy attribute, and also proposal to > rewrite the description of what this attribute means. I think this > proposal overall is good, in that it gives a more precise description > without changing the intent. > [CNG] It wasn't planned to change the intent. Only to clarify. > > But I have a few questions about the proposal (listed below). Also I > wonder if alternatively we could just remove the scene-switch-policy > (and proposed capture source synchronization attribute) altogether, if > we decide to move forward with the multiple content capture (MCC) with > sync-id attribute. It seems to me that by using MCC with sync-id it > can accomplish the same thing in more general way without needing > scene-switch-policy. What do others think? > [CNG] The intention was that if we accept the MCC concept that we wouldn't need the "Scene-switch-policy" attribute and thus it could be deleted. So I agree. > > Questions on section 3.3.3 (these questions are moot if we decide to > remove this attribute altogether): > > 1.I think it would be useful to add a reference back to the use case > document, saying the motivation for this is to enable the use cases > related to site-switch and segment-switch as described in the use case > document. Would that help readers understand what this is all about? > [CNG] OK by me. > > 2.I don’t understand the statement “However it is assumed that each > capture within the CSE will contain the same number and set of > sources.” Is this talking about an MCC and the other MCs that could > contribute to it? Why would each capture in a CSE have to contain the > same number and set of sources? > [CNG] No this isn't considering an MCC. Its considering what the consumer can expect to receive. Given the example in sect 3.3.3 CSE1(VC1,VC2,VC3). It means that the consumer should always expect to receive 3 media streams. Not one or two as the CSE indicates that 3 VCs make up a scene. e.g. if EP(1) only had 1VC, EP(2) had 2VCs and EP(3) had 3VCs then in the synchronous switching case only when you switched to EP(3) would the encodings associated with VC1,VC2,VC3 have media. We could specify other behaviour for this, I took the simplest behaviour when proposing the update. > 3.I don’t understand the two paragraphs about the “Switched” attribute > and “Composed” attribute. It sounds like a proposal to subtly change > the meaning of these attributes if the advertiser also uses the > Capture Source Synchronization attribute. I don’t get the intent of > this, can you explain further? > [CNG] The intent of those paragraphs is to explain the interaction between the "Capture Source Synchronisation" and "switched" and "composed" attributes. I.e. what does it mean when they are set together? This aspect was missing from the framework. Those paragraphs are an attempt to document it. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From roberta.presta@unina.it Mon Oct 14 05:27:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C30711E817E for ; Mon, 14 Oct 2013 05:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDhNx1VgWVti for ; Mon, 14 Oct 2013 05:27:34 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4654011E8127 for ; Mon, 14 Oct 2013 05:27:33 -0700 (PDT) Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r9ECRUA4020300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Oct 2013 14:27:31 +0200 Message-ID: <525BE333.2050206@unina.it> Date: Mon, 14 Oct 2013 14:27:31 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christian Groves References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> <52576D96.3050606@nteczone.com> In-Reply-To: <52576D96.3050606@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 131014-0, 14/10/2013), Outbound message X-Antivirus-Status: Clean Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:27:41 -0000 Hello Christian, thank you for your comments. Please see below. Il 11/10/2013 05:16, Christian Groves ha scritto: > Hello Simon and Roberta, > > Thanks for the updates. I had a look and have a few comments below: > > 1. Sect.1 bullet 2 : The Config allows captures and encodings to be > selected so I would propose to update the wording: > 2. enabling a MC to request the desired resulting> multimedia streams from the offering MP. We have considered a stream as a capture encoding, i.e. the association of a media capture and a capture encoding, as per the framework definition of "stream". We will recall such definition in section "Terminology". > > 2. Sect.3 1st para: The MC not only requests the stream but receives > them. I propose updating the text: > ...while the client side is represented by the Media Consumer, which > requests the media streams. > OK. > 3. Sect. 3 3rd para: Similar comment to 1 above. I propose rewording: > The MC selects the desired streams coming from the MP > by using... Same considerations of point 1. > > 4. Sect. 3.x: The tables have "Type". Is this really needed as it is > explained in the text. Plus 3.2 the message name is "Response" and the > type is "Response". It seems superfluous. > The type of the message is an important characteristic. Indeed, notifications, requests and responses are the three main classes of CLUE messages. A request is issued only by a MC to a MP, and each request expects a response message coming from the opposite direction. A notification (like the advertisement) is an asynchronous announce. CLUE messages are demultiplexed in a CLUE endpoint on the basis of the type of the message: - A MC receives only responses and notifications, while it issues only requests - A MP receives only requests and issues responses and notifications CLUE messages are expected to belong to one of the aforementioned categories (and this is reflected in the schema definitions). The draft definitely needs more text about it. > 5. Sect.3.3: Nit: Rescription should be "Description" > OK. > 6. Sect 3.x: Are we missing a message? There is a Response for a > Configure but there is no response to an Advertisement. If the MC > receives an Advertisement there should at least be an indication that > it was received OK. Why would a response to a Configure or an > Advertisement be handled differently. I think the RE-ADV should only > be used when the MC needs to refresh its state, not for indicating > that there is a Advertisement message syntax problem, etc. Note: this > is a similar comment as Paul's regarding the application level ACK. I > don't think that a ADV needs an immediate CFG. > Currently in the draft there isn't a mechanism that acknowledge the ADV. We have not considered acknowledge mechanisms at all and we have tried to only rely on timeouts and retry mechanisms, i.e., if nothing happens within the timeout interval and the timeout fires, then the message is issued again. This is repeated until the max number of retry is achieved. We can discuss the introduction of acks for notification messages. An acknowledgement mechanism should not be needed by the request-response couples since the responses act as acks. The READV functionality could be then reduced to the one of a simple refresh request, since problems with the received ADV could be treated otherwise. > 7. Sect.5 2nd para: What is meant by ".. if the number of trials is > below the retry > threshold...? > Explained in answer to point 6. We will correct the text in order to make it clearer. > 8. Sect.5 3rd para: As per 6 I think that rather than RE-ADV a > "ADV-RESP" would be sent indicating an error condition. A MP should be > the one to decide to determine if another ADV is sent. > I'm OK with decoupling the READV functionality from the problems with a received ADV as per point 6. > 9. Sect.5 3rd para: This indicates that if there is an error with the > ADV the MC goes from state "receive ADV" to "IDLE". What doesn't > appeared to be covered is what happens if the MC is in "IN CALL" state > when it receives the ADV and there's an error? I would assume that > rather than go to IDLE on error that it would go back to "IN CALL"? > The state could potentially be affected by what error is received. The IN CALL state indicates that the media streams the MP and the MC have agreed on (and are aware of) the media streams to be exchanged within the call. When a MC/MP goes out from the IN CALL state it means that something has changed and that the media streams currently exchanged may not be aligned with the ones known at the CLUE level. For example, if a MP stops sending a certain media stream for any reason, it issues a new advertisement to the MC after such change. Once received the ADV, the MC then flows from the IN CALL state to the ADV RECEIVED one and, if there are problems with the ADV, moves back to the IDLE state, which is a state where MP and MC are not aligned with the streams actually involved in the conference. It does not mean that there are no streams currently exchanged between the peers. > > 10. Sect.5 General: The term "CALL" is used. For me this encompasses > the entire session. i.e. to be "IN CALL" it would assume the CLUE > negotiation is done, the media streams are configured and media is > flowing etc. As this is describing a CLUE state machine should we > instead use CLUE specific terminology? i.e. "IN CALL" -> "CAPTURES > NEGOTIATED" etc. > The IN CALL state can be seen as a "negotiation completed" state where both the CLUE parties have successfully agreed on the media streams to be exchanged at the CLUE level. We could change the name of the state or alternatively add more text to clarify the concept. > 11. Sect. 6 General: As per 6 above I think there should be an > application level response, either saying success or error. Once that > is received then it should wait for a CONFIG or RE-ADV. > See point 6 answer. > 12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that > has error when it is an a IN CALL state I would expect that it remain > in an in call state. Rather than go back to IDLE. > See point 9 answer. > 13 General: Do we need to define the scope of the states that they > only cover CLUE? or do they have further scope. E.g. If the CLUE state > is Terminated does this indicate some other behaviour that the MP or > MC should do? i.e. send updated SIP O/A to remove media. Btw, I'm not > suggesting this extended scope. > I think it is still premature in this phase. > 14 Sect 7. Para.1: Nit - Suggested update: "... the message cannot be > processed ." Some processing has to be done to determine > version. > OK. > 15 Sect 7. Para.3: Nit - "subsequet" -> "subsequent" > OK. > 16 Sect 7. Para.3: The changes need to be backwards compatible not > only in terms of schema but also semantically and procedurally as well. I agree. We will add text about that concept. > > 16 Sect 7. Para.4: I'm not a big supporter of having versions related > to different CLUE protocol drafts. Compliance to a CLUE version isn't > just based on the version of the schema. e.g. what if we change the > procedural handling of an existing XML element? The schema wouldn't > change. I'd prefer simply working towards v1.0. > > 17 Sect 7. Para.5: nits: "ascpect"->"aspect", > "explicitely"->"explicitly", "would up"-> "would up" > OK. > 18 Sect 8.1 para 4: It mentions here that " Elements or attributes > from unknown namespaces MUST be ignored". If the MP or MC receives > such an element I would expect that an error be returned to the ADV or > CFG message it contained or? We have conceived an extensions negotiation mechanism (via the OPTIONS request/response message) that should avoid to fall into that situation (i.e. when a peer sends a message with xml elements coming from unknown namespaces). However, extensions as elements placed in correspondence of are typically conceived to indicate something more than the basic behavior of the CLUE negotiation. If the other part is not able to understand that "something more", it does nothing less than the ordinary behavior. > > 19 Sect 8.1: I guess each of the last 3 bullets should be possible > depending on the type of data. I think that we need to separate the > actual syntax and structures (i.e. CS, CSEs, STSs etc) from the > Captures attributes. It should be possible to create new attributes or > update their value through an extension mechanism rather than need to > update the protocol version. Is this what is meant by the 3rd bullet? > Updates to the syntax and structures should need a new version. > Yes, the third bullet refers to a mechanism that enables to create new attributes without update the data model schema version and preserving the compatibility with it. However, according to that possibility, new attributes should be defined elsewhere and also in this case the new schema should be linked wherever we want to exploit that extension. > 19 Sect 8.2: I think a new message does need a new version so this > should be the ONLY chance. As per the OPTIONS mechanism we are able to handle both data model and protocol updates. In that vision, there are stable protocol and data model versions (with associated schema files), and extensions defined in other XML schemas. Let's say that we have: 1) an extension for the data model, i.e. a schema file S1 defining new data model elements. For example, we can imagine a schema defining other audio capture attributes represented by XML elements placed in correspondence of the element in the data model audio capture definition. 2) an extension for the protocol, i.e. a schema file S2 defining for example a new notification message that makes the MP able to inform the MC about the availabilty and the status of video captures only. The MC supporting both extensions issues an OPTIONS containing the references of both S1 and S2. The MP supporting both extensions recognizes the schemas and then knows that it can issue specific notifications according to the format provided in S2 and that it can use also the features defined in S1 to describe the available audio captures. > > 20 Sect 9 Para.3: Nit instatiated->instantiated. > OK. > 21 Sect 9: I think we had some previous discussion that the OPTIONs > should only occur once at the start of the CLUE channel. This didn't > seem to be covered. > Yes, the OPTIONS occurs once at the start of the CLUE channel. It is not written explicitly, but there is a description and a picture of the mechanism explained in sec. 9.1. We will add these important details in the next version. > 22 Sect 9: Why is the MC responsible for sending the OPTIONS message? > I would have thought that as the MP sends the ADV (which is > effectively the first message) that it would send it? > With the introduction of the OPTIONS message, the ADV is no more the first message to be sent. The state machines represent the evolution of the MP and of the MC after that the version of the protocol and the involved extensions have been agreed with the OPTIONS message. The OPTIONS message is conceived as a request that expects a response. It is the MC that issues that request, providing to the MP the supported extensions and the higher supported protocol version. In that way, the MP can select the extensions in the set supported by the MC and then use only information that is understood by the MC. Roberta > Regards, Christian > > On 8/10/2013 10:21 PM, Simon Pietro Romano wrote: >> ...here it is. >> >> Simon >> >> Inizio messaggio inoltrato: >> >>> *Da: *internet-drafts@ietf.org >>> *Oggetto: **New Version Notification for >>> draft-presta-clue-protocol-02.txt* >>> *Data: *08 ottobre 2013 13:20:31 GMT+02:00 >>> *A: *Roberta Presta >> >, Simon Pietro Romano >>> >, Simon Romano >>> > >>> >>> >>> A new version of I-D, draft-presta-clue-protocol-02.txt >>> has been successfully submitted by Roberta Presta and posted to the >>> IETF repository. >>> >>> Filename:draft-presta-clue-protocol >>> Revision:02 >>> Title:CLUE protocol >>> Creation date:2013-10-08 >>> Group:Individual Submission >>> Number of pages: 26 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-presta-clue-protocol >>> Htmlized: http://tools.ietf.org/html/draft-presta-clue-protocol-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-02 >>> >>> Abstract: >>> The CLUE protocol is an application protocol conceived for the >>> description and negotiation of a CLUE telepresence session. The >>> design of the CLUE protocol takes into account the requirements and >>> the framework defined, respectively, in [I-D.ietf-clue-framework] and >>> [I-D.ietf-clue-telepresence-requirements]. The companion document >>> [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as >>> well as on the SIP/SDP session establishment phase. We herein focus >>> on the application level perspective. Message details, together with >>> the behavior of both the Media Provider and the Media Consumer are >>> discussed. >>> >>> >>> >>> >>> 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 >>> . >>> >>> The IETF Secretariat >>> >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Oct 14 06:40:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E9921F9E83 for ; Mon, 14 Oct 2013 06:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.151 X-Spam-Level: X-Spam-Status: No, score=-102.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QbOwAR6sLrn for ; Mon, 14 Oct 2013 06:40:39 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 386F821F9CAF for ; Mon, 14 Oct 2013 06:40:39 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id cy11so5144605qeb.26 for ; Mon, 14 Oct 2013 06:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FC0aO+MZlrQBiMd/HI0aH5HPR48C9opST6DrzoAMnDg=; b=muJI9+uzR8LXxq6ryanUv2irlsWpQayoOLpqjrJJ83tYnKviabVdu2VxBVwzXL/DRE 5kIgFPG991AUhX+OrgZ/WZgSWqK1AZ8MKCw85KATcZMJPrLdzjx0Vux14/Xr6FgYUDOe 1VdVUSPYjuAvpNNkAMFQEj7YIe5uUHaP8Un3BIVrXP9xWYO3x1LXk3RX4+26F59PcsD7 RbbrdU0i84sU9+zebWfilXcICgV3Rr8hoHvOblHHdUoOR7sZFS1fv/WB45ly5vVnbahH P1i64bCazCXjnZybR2wod5y/1NcGvI3pjnOjf4mU0dHt5Kf3wrqDQOzrlomB4yT7pPNw LoiQ== MIME-Version: 1.0 X-Received: by 10.224.54.209 with SMTP id r17mr22507342qag.16.1381758038536; Mon, 14 Oct 2013 06:40:38 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Mon, 14 Oct 2013 06:40:38 -0700 (PDT) In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6037A010A@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> <521D7313.6030609@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6037A010A@CRPMBOXPRD07.polycom.com> Date: Mon, 14 Oct 2013 08:40:38 -0500 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=089e015375320d911404e8b39dd2 Cc: CLUE Subject: Re: [clue] Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 13:40:42 -0000 --089e015375320d911404e8b39dd2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mark, I apologize for not getting my action items done sooner - I've been traveling solid for the past 4 weeks. Now that I'm back to a big screen, I should be able to get these edits to you. From a WG perspective, I don't think any of this is normative, so I think it will be okay to submit the changes and then the WG can provide any feedback on those changes as it's hard to just review new text out of context (I will be pulling text from earlier versions of the FW with slight modifications). As mentioned previously, we would like to do a pre-WGLC on this document very soon. Given the closeness to the meeting, we should likely wait for any changes based on discussion of issues in Vancouver. We can then start a 3 week review (since we will be overlapping with US thanksgiving). Thanks for following up on this. Mary. On Fri, Oct 11, 2013 at 1:56 PM, Duckworth, Mark wrote: > Mary,**** > > I=92m updating the framework according to this discussion. But there are= a > few things still open:**** > > **1. **For your comment number 2, you offered to take a pass at > moving some information out of the Introduction into a new section or int= o > the overview. That would be very helpful to me, thanks. > [MB] I will get that to you within the next day or so. [/MB] > **** > > **2. **You offered to create a new ascii diagram based on an old > one from section 5 of the -02 version > [MB] Ditto [/MB] > **** > > **3. **Using All Caps for defined terms =96 personally I agree with > you I prefer the terms as lower case (both as an editor and as a reader). > Does anybody else have input to this?**** > > ** ** > > Mark**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Wednesday, August 28, 2013 5:59 PM > *To:* Christian Groves > *Cc:* CLUE > > *Subject:* Re: [clue] Fwd: Comments on CLUE Framework**** > > ** ** > > HI Christian,**** > > ** ** > > Thanks for your comments - my responses are below [MB2].**** > > ** ** > > Mary.**** > > ** ** > > On Tue, Aug 27, 2013 at 10:48 PM, Christian Groves < > Christian.Groves@nteczone.com> wrote:**** > > Hello Mary, > > Please see my responses below. > > Regards, Christian**** > > > > On 28/08/2013 1:53 AM, Mary Barnes wrote:**** > > Hi folks, > > In reviewing the FW in order to tease out specific security threats that = a > CLUE solution must address, I came up with a set of comments that I would > like the WG to consider. Below is the thread of discussion. Additional > feedback (both agreeing with the proposal or not - with details if you > don't agree) from the WG is necessary in order for Mark to include these > changes. As noted, I will provide some concrete text to go along with a > couple of the suggestions. Please send feedback no later than Sept. 3rd > CoB. No responses will be interpreted as support for the changes. > > Of course, there will be an opportunity to provide comments on the update= d > version of the document as well later, but it's always helpful to get tha= t > feedback before incorporating changes. > > Regards, > Mary > --as an individual > > ---------- Forwarded message ----------**** > > From: *Mary Barnes* mary.ietf.barnes@gmail.com>> > Date: Tue, Aug 27, 2013 at 10:18 AM > Subject: Re: Comments on CLUE Framework**** > > To: "Duckworth, Mark" Mark.Duckworth@polycom.com>> > Cc: Paul Kyzivat > > > > Thanks for the response. I have a few responses below [MB]. I will forwar= d > the comments to the list to get feedback from the WG. > > Mary. > > **** > > On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark < > Mark.Duckworth@polycom.com > wrote: > > Hi Mary, > > Thanks for the good suggestions. In general, all your suggestions > make sense to me. > > More comments below. > > Mark**** > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Sent:* Wednesday, August 21, 2013 2:23 PM > *To:* Duckworth, Mark > *Cc:* Paul Kyzivat > *Subject:* Comments on CLUE Framework**** > > > > So, here are the comments I have on the framework based on my > re-read to tease out specifics for the security requirements. One > major thing I noticed is that some of the structural concerns I > have are with regards to some of the bigger changes made between > the -08 and -09. Again, I looked at diffs after the various > revisions were submitted and thought the content was okay at the > time. But, as I'm now re-reading from beginning to the end (for > the first time in a long time), there are some areas that I really > stumbled over and I think some more reorganization/editorial work > is needed before we could forward this doc for publication. Having > been a gen-art reviewer for a decade, I think similar issues would > be raised on the document by other directorate reviewers (and ADs) > if we don't make a few changes. I wanted to vet these with you > prior to posting to the WG mailing list. > > Paul - I'm reviewing this from the perspective that was discussed > on WG chairs mailing list with regards to doing multiple reviews > as part of the PROTO process. > > Mary. > > Comments: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Major: > > ------- > > 1) The abstract needs some beefing up, including setting some > context. Per my comment 3 below, I think it's important to > highlight that the protocol outlined in this document augments and > does not replace SIP O/A. I would suggest to update the text in > the Abstract something like the following. : > > OLD: > > This document offers a framework for a protocol that enables > > devices in a telepresence conference to interoperate by specifyin= g > > the relationships between multiple media streams. > > NEW: > > This document defines a framework for a protocol to enable devices > in a telepresence conference to interoperate. The protocol enables > communication of information about multiple media streams so a > sending system, receiving system or intermediate system can make > reasonable decisions about transmitting, selecting and rendering > the media streams. This protocol is used in addition to SIP > signaling for setting up a telepresence session.**** > > */[Duckworth, Mark] sounds good./***** > > /*[CNG] CLUE is point to point, (i.e. sent from one endpoint and > terminated at another)*/ so there is no intermediate system from a CLUE > perspective. I would strike the text regarding intermediate system.**** > > [MB2] My understanding was that intermediate system is something line an > MCU or conference focus. However, I think you are correct in that sendi= ng > system and receiving system are sufficient. I also double checked and we > don't use the term intermediate system in the requirements or use cases > expect in the Heterogeneous system use case when it's talking about > transcoding. [/MB2]**** > > ** ** > > 2) Introduction: I really stumbled over the level of detail that > the document jumps into in the Introduction (which is before any > terminology). It goes from a high level description of the > problem, highlighting that this document provides a framework > based on the use cases and requirements, directly to the > statement: "Conceptually distinguished are Media Providers and > Media Consumers". I also think the level of detail does not belong > in the introduction. To me that's more overview/motivation. > Previously, the introduction provided some text as to what is in > the remainder of the document. I think some of the old text needs > to be pulled back into this introduction and the text starting > with the "Conceptually" paragraph might serve very well in a > "Motivation" section just prior to the overview (after the > terminology section). I also think the "Conceptually" sentence > could be replaced with text that provides a better introduction to > the section, perhaps linking the term "consumer" to "receiver" and > "provider" to "sender" that are mentioned in the abstract text I > suggested above. Maybe something like the following: > > OLD: > > Conceptually distinguished are Media Providers and Media Consumers. > > NEW: > > This document introduces the term Media Provider to represent the > entity that is sending the media and Media Consumer to represent > the entity that is receiving the media.**** > > */[Duckworth, Mark] sounds good. But it will take some work to**** > > > figure out detailed changes between introduction and overview, and***= * > > bringing back some old text./***** > > > > [MB] Yeah, I know. I can make a pass at that if you would find that > helpful. [/MB]**** > > [CNG] OK in theory, I'll wait for the concrete text.**** > > > *//***** > > > > 3) The fact that SIP and SDP offer/answer are used for basic > session setup as well as when needed during the session (as > described in detail in solution documents) isn't highlighted early > enough or often enough. Given we've had lots of folks thinking we > were trying to invent something new entirely, I think it's really > important for this be quite explicit early on. I think this > relates to additional text that should be in the introduction. I > think something like the following will be sufficient: > > NEW: > > This document identifies the protocols necessary to achieve the > functionality per the use cases and requirements. The basic > session setup for the use cases is based on SIP [RFC 3261] and SDP > offer/answer [RFC 3264]. The details with regards to this > signaling are provided in the solution documents. In addition to > basic SIP & SDP offer/answer, CLUE specific signaling is required > to exchange the information describing the multiple media streams. > The details of this signaling and the information required to be > exchanged is described in subsequent sections of this document.**** > > */[Duckworth, Mark] sounds good. We tried to say this about using**** > > > SDP O/A, but not until the end of section 4. It does seem better**** > > to say it earlier./***** > > /*[CNG] I think we should also make it clear that whilst "SIP and SDP O/A= " > are mainly discussed it does not prevent CLUE from being used in networks > where there are other call controls i.e. H.32x, WebRTC, what ever the > future holds.... */**** > > [MB2] I don't disagree with what you say but I don't think we should say > anything about that given our charter, which limits the work to SIP. That= 's > opening up the question as to how that will work, whether additional > specification is required,etc. [/MB2] **** > > > Minor: > > -------- > > 1) General: I realize that at some point, someone changed all the > terms to appear as formal names - e..g., capitalized. Personally, > I prefer just having the terms all lower case as I find it easier > to read that way. However, the RFC editor leaves the choice to the > document editor, but it needs to be consistent. So, another pass > is needed as I noticed a few that weren't caps that should be and > some that were caps that shouldn't be. For example, in the > "Conceptually" paragraph I refer to above, "Renderer" is in Caps, > but it's not defined as a reserved word in the terminology and I'm > assuming that the intent is to only have nouns in all caps? You > will find it awkward if you try to change every occurrence of the > reserved words as sometimes it just won't read right (which is > another reason to just use lower case).**** > > */[Duckworth, Mark] I don=92t care either way. I think it was**** > > > Stephan who first suggested capitals, in the old terminology**** > > document./***** > > > > [MB] Again, either way is okay. But, there are some places where it's not > all caps. I also think using lower case is easier just from a basic editi= ng > standpoint as it's more natural IMHO to just type the words and not have = to > CAP. [/MB]**** > > [CNG] It can be helpful to have capitalised terms to distinguish when > you're talking about a entity Renderer vs a function "render".**** > > *//***** > > > > 2) Introduction: The text in the intro (3rd para) (that I'm > suggesting to move to Motivation section) that starts with > "Motivations" reads a little funky. I suggest to reword something > like: > > OLD:**** > > Motivations for this document (and, in fact, for the existence > ofthe CLUE protocol) include:**** > > > > NEW: > > > The motivations for the framework outlined in this document include > the following:**** > > */[Duckworth, Mark] sounds good/***** > > /*[CNG] OK*/**** > > > 3) Introduction: List item (1). I was going to suggest rewording > (as it reads as if the endpoints described are only specific to > this document), but it's not clear to me exactly what that item is > trying to say. Can it be changed to something like the following > and still mean what is intended? [As an aside "Media Renderer" > isn't a reserved word - I think perhaps if you add a definition > for "Renderer" that would help. I actually think that's probably > necessary anyways as I think it's important to distinguish "Media > Renderer" from "Media Consumer"]. > > OLD: > > (1) Endpoints according to this document can, and usually do, have > multiple Media Captures and Media Renderers, that is, for example,multipl= e > cameras and screens. While previous system designs were able to set up > calls that would light up all screens and cameras > > (or equivalent), what was missing was a mechanism that can associate > the Media Captures with each other in space and time. > > NEW: > > > (1) Endpoints in telepresence systems typically have multiple Media > Captures and Media Renderers, e.g., multiple cameras and screens. While > previous system designs were able to set up calls that would capture medi= a > using all cameras and display media on all screens, for example, there is > no mechanism that can associate these Media Captures with each other in > space and time. > > **** > > */[Duckworth, Mark] Yes, I think that says the intent better./***** > > /*[CNG] */I'd propose a slight reword "Endpoints in telepresence systems > typically have multiple Media Capture and Media Render devices, e.g., > multiple cameras and screens. ..."**** > > [MB2] That sounds good to me. [/MB] **** > > ** ** > > > 4) Section 4, last two paragraphs. I'm really wondering how much > needs to be said (if anything) about "legacy" in this document. > This document is defining what we need for CLUE. The signaling > solution document will of course get into how this works. But, I > think we could just delete the next to last paragraph and condense > the one on RTP to reference the WG RTP mapping mapping document**** > > */[Duckworth, Mark] okay/***** > > /*[CNG] I don't think one paragraph describing this fall back in the > framework is too much. I think its helpful to explain fallback behaviour.= */ > **** > > [MB2] If you read it in the context of that section, it doesn't quite see= m > to fit. It leaves more questions than providing answers in my opinion. = It > seems to be some leftover text from when the document had a lot more deta= il > - e.g., the text about legacy devices is totally unnecessary as they aren= 't > referenced elsewhere in the framework any longer. I think perhaps the id= ea > of fallback when the device doesn't support CLUE can be stated much more > concisely. I don't have a proposal right off, but will think about it. > Unless someone else has suggestions. [/MB2]**** > > > 5) Somewhat General. There was a diagram in Section 5 in the -02 > version that was dropped in the -03. I really think that more > diagrams would help to understand this stuff.**** > > */[Duckworth, Mark] That was the precursor to this. The -02**** > > > diagram doesn=92t really say much, but I could try to update it. The*= *** > > one below is a bit much to convert to ASCII./***** > > > > [MB] I can convert that to ascii art. I did all the diagrams in RFC 5239. > This is just a tad more complicated than some of those. [/MB]**** > > *//* > > *//***** > > > > 6) Per my other email, I believe these should all be normative > references and RFC 3264 needs to be added. > > **** > > [CNG] ???**** > > [MB2] Sorry, there was another email exchange that I hadn't yet sent to > the list about making this document standards track and adding some more > references. I'll send that now. [/MB2] **** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --089e015375320d911404e8b39dd2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
      Hi Mark,

      I apologize for not getting my= action items done sooner - I've been traveling solid for the past 4 we= eks. =A0Now that I'm back to a big screen, I should be able to get thes= e edits to you. =A0 From a WG perspective, I don't think any of this is= normative, so I think it will be okay to submit the changes and then the W= G can provide any feedback on those changes as it's hard to just review= new text out of context (I will be pulling text from earlier versions of t= he FW with slight modifications).=A0

      As mentioned previously, we would like to do a pre-WGLC= on this document very soon. =A0Given the closeness to the meeting, we shou= ld likely wait for any changes based on discussion of issues in Vancouver. = =A0 We can then start a 3 week review (since we will be overlapping with US= thanksgiving).

      Thanks for following up on this.

      Mary.=A0


      On Fri, Oct 11, 2013 at 1:56 PM, Duckworth, Mark <Mark.D= uckworth@polycom.com> wrote:

      Mary,<= u>

      I=92m updating the framew= ork according to this discussion.=A0 But there are a few things still open:=

      1.=A0=A0=A0=A0=A0=A0 For your comment number 2, you offered to take a pa= ss at moving some information out of the Introduction into a new section or= into the overview.=A0 That would be very helpful to me, thanks.

      [MB] I will get that to you within the next d= ay or so. [/MB]=A0

      2.=A0=A0=A0=A0=A0=A0 You offered to create a new ascii diagram based on an old one from= section 5 of the -02 version

      [MB] Ditto [/MB]=A0

      3.=A0=A0=A0=A0=A0=A0 Using All Caps for defined terms =96 personally I a= gree with you I prefer the terms as lower case (both as an editor and as a = reader).=A0 Does anybody else have input to this?

      =A0<= /p>

      Mark

      =A0<= /p>

      From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
      Sent: Wednesday, August 28, 2013 5:59 PM
      To: Christian Gro= ves
      Cc: CLUE


      Subject: Re: = [clue] Fwd: Comments on CLUE Framework

      =A0

      HI = Christian,

      =A0

      Thanks for your = comments - my responses are below [MB2].

      =A0

      Mary.

      =A0

      On T= ue, Aug 27, 2013 at 10:48 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:

      Hello Mary,

      Please see my responses below.
      Regards, Christian


      On 28/08/2013 1:53 AM, Mary Barnes wrote:

      Hi folks,

      In reviewing the FW in order t= o tease out specific security threats that a CLUE solution must address, I = came up with a set of comments that I would like the WG to consider. Below = is the thread of discussion. Additional feedback (both agreeing with the pr= oposal or not - with details if you don't agree) from the WG is necessa= ry in order for Mark to include these changes. As noted, I will provide som= e concrete text to go along with a couple of the suggestions. Please send f= eedback no later than Sept. 3rd CoB. No responses will be interpreted as su= pport for the changes.

      Of course, there will be an opportunity to provide comments on the upda= ted version of the document as well later, but it's always helpful to g= et that feedback before incorporating changes.

      Regards,
      Mary
      --as an individual

      ---------- Forwarded message ----------=

      From: *Mary Barnes* <mary.ietf.barnes@g= mail.com <mailto:mary.ietf.barnes@gmail.com>>
      Date: Tue, Aug 27, 2013 at 10:18 AM
      Subject: Re: Comments on CLUE Framew= ork

      To: "Duckworth, Mark" <Mark.Duckworth@polycom.com <mail= to:Mark.Duc= kworth@polycom.com>>
      Cc: Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>


      Than= ks for the response. I have a few responses below [MB]. I will forward the = comments to the list to get feedback from the WG.

      Mary.

      On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark = <Mark.Du= ckworth@polycom.com <mailto:Mark.Duckworth@polycom.com>> wrote:

      =A0 =A0 Hi Mary,

      =A0 =A0 Thanks for the good suggestions. In gen= eral, all your suggestions
      =A0 =A0 make sense to me.

      =A0 =A0 More= comments below.

      =A0 =A0 Mark

      =A0 =A0 *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com
      =A0 =A0 <mailto:mary.ietf.barnes@gmail.com>]
      =A0 =A0 *Sent:* Wednesday, A= ugust 21, 2013 2:23 PM
      =A0 =A0 *To:* Duckworth, Mark
      =A0 =A0 *Cc:* Pa= ul Kyzivat
      =A0 =A0 *Subject:* Comments on CLUE Framework



      =A0= =A0 So, here are the comments I have on the framework based on my
      =A0 = =A0 re-read to tease out specifics for the security requirements. One
      = =A0 =A0 major thing I noticed is that some of the structural concerns I
      =A0 =A0 have are with regards to some of the bigger changes made between=A0 =A0 the -08 and -09. Again, I looked at diffs after the various
      =A0= =A0 revisions were submitted and thought the content was okay at the
      = =A0 =A0 time. But, as I'm now re-reading from beginning to the end (for=
      =A0 =A0 the first time in a long time), there are some areas that I really<= br>=A0 =A0 stumbled over and I think some more reorganization/editorial wor= k
      =A0 =A0 is needed before we could forward this doc for publication. Ha= ving
      =A0 =A0 been a gen-art reviewer for a decade, I think similar issues would<= br>=A0 =A0 be raised on the document by other directorate reviewers (and AD= s)
      =A0 =A0 if we don't make a few changes. I wanted to vet these wit= h you
      =A0 =A0 prior to posting to the WG mailing list.

      =A0 =A0 Paul - I= 9;m reviewing this from the perspective that was discussed
      =A0 =A0 on WG= chairs mailing list with regards to doing multiple reviews
      =A0 =A0 as p= art of the PROTO process.

      =A0 =A0 Mary.

      =A0 =A0 Comments:

      =A0 =A0 =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

      =A0 =A0 Major:

      =A0 =A0 -------

      =A0 = =A0 1) The abstract needs some beefing up, including setting some
      =A0 = =A0 context. Per my comment 3 below, I think it's important to
      =A0 =A0 highlight that the protocol outlined in this document augments and<= br>=A0 =A0 does not replace SIP O/A. I would suggest to update the text in<= br>=A0 =A0 the Abstract something like the following. :

      =A0 =A0 OLD:=

      =A0 =A0 =A0 =A0 =A0This document offers a framework for a protocol = that enables

      =A0 =A0 =A0 =A0 devices in a telepresence conference to interoperate by= specifying

      =A0 =A0 =A0 =A0 the relationships between multiple media= streams.

      =A0 =A0 NEW:

      =A0 =A0 This document defines a framew= ork for a protocol to enable devices
      =A0 =A0 in a telepresence conference to interoperate. The protocol enables<= br>=A0 =A0 communication of information about multiple media streams so a=A0 =A0 sending system, receiving system or intermediate system can make<= br>=A0 =A0 reasonable decisions about transmitting, selecting and rendering=
      =A0 =A0 the media streams. This protocol is used in addition to SIP
      =A0 = =A0 signaling for setting up a telepresence session.

      =A0 =A0 */[Duc= kworth, Mark] sounds good./*

      /*[CNG] CLUE is point to point, (i.e. s= ent from one endpoint and terminated at another)*/ so there is no intermedi= ate system from a CLUE perspective. I would strike the text regarding inter= mediate system.

      [MB2] My understanding was that intermediate sy= stem is something line an MCU or conference focus. =A0 However, I think you= are correct in that sending system and receiving system are sufficient. I = also double checked and we don't use the term intermediate system in th= e requirements or use cases expect in the Heterogeneous system use case whe= n it's talking about transcoding. =A0[/MB2]

      =A0

      =A0 =A0 2) Introduction: I really stumbled over= the level of detail that
      =A0 =A0 the document jumps into in the Introdu= ction (which is before any
      =A0 =A0 terminology). It goes from a high level description of the
      =A0 = =A0 problem, highlighting that this document provides a framework
      =A0 = =A0 based on the use cases and requirements, directly to the
      =A0 =A0 sta= tement: "Conceptually distinguished are Media Providers and
      =A0 =A0 Media Consumers". I also think the level of detail does not be= long
      =A0 =A0 in the introduction. To me that's more overview/motivat= ion.
      =A0 =A0 Previously, the introduction provided some text as to what = is in
      =A0 =A0 the remainder of the document. I think some of the old text needs=A0 =A0 to be pulled back into this introduction and the text starting=A0 =A0 with the "Conceptually" paragraph might serve very well = in a
      =A0 =A0 "Motivation" section just prior to the overview (after th= e
      =A0 =A0 terminology section). I also think the "Conceptually"= ; sentence
      =A0 =A0 could be replaced with text that provides a better in= troduction to
      =A0 =A0 the section, perhaps linking the term "consumer" to "= ;receiver" and
      =A0 =A0 "provider" to "sender" t= hat are mentioned in the abstract text I
      =A0 =A0 suggested above. Maybe = something like the following:

      =A0 =A0 OLD:

      =A0 =A0 Conceptually distinguished are Media Provid= ers and Media Consumers.

      =A0 =A0 NEW:

      =A0 =A0 This document i= ntroduces the term Media Provider to represent the
      =A0 =A0 entity that i= s sending the media and Media Consumer to represent
      =A0 =A0 the entity that is receiving the media.

      =A0 =A0 */[Duckworth, Mark] sounds good. But it will tak= e some work to


      =A0 =A0 fig= ure out detailed changes between introduction and overview, and

      =A0 =A0 bringing back some old text./*<= u>



      [MB] Yeah, I know. I can make= a pass at that if you would find that helpful. [/MB]

      [CNG] OK in theory, I'll wait for the concrete t= ext.


      =A0 =A0 *//*=



      =A0 = =A0 3) The fact that SIP and SDP offer/answer are used for basic
      =A0 =A0 session setup as well as when needed during the session (as
      =A0 = =A0 described in detail in solution documents) isn't highlighted early<= br>=A0 =A0 enough or often enough. Given we've had lots of folks thinki= ng we
      =A0 =A0 were trying to invent something new entirely, I think it's real= ly
      =A0 =A0 important for this be quite explicit early on. I think this=A0 =A0 relates to additional text that should be in the introduction. I<= br>=A0 =A0 think something like the following will be sufficient:

      =A0 =A0 NEW:

      =A0 =A0 This document identifies the protocols nece= ssary to achieve the
      =A0 =A0 functionality per the use cases and require= ments. The basic
      =A0 =A0 session setup for the use cases is based on SIP= [RFC 3261] and SDP
      =A0 =A0 offer/answer [RFC 3264]. The details with regards to this
      =A0 = =A0 signaling are provided in the solution documents. In addition to
      =A0= =A0 basic SIP & SDP offer/answer, CLUE specific signaling is required<= br>=A0 =A0 to exchange the information describing the multiple media stream= s.
      =A0 =A0 The details of this signaling and the information required to be=A0 =A0 exchanged is described in subsequent sections of this document.=

      =A0 =A0 */[Duckworth, Mark] sou= nds good. We tried to say this about using


      =A0 =A0 SDP O/A, but not until the end of s= ection 4. It does seem better

      =A0 =A0 to say it earlier./*<= /p>

      /*[CNG] I think we should also make it clear that whilst "SIP and SDP = O/A" are mainly discussed it does not prevent CLUE from being used in = networks where there are other call controls i.e. H.32x, WebRTC, what ever = the future holds.... */

      [MB2] I don't disagree with wh= at you say but I don't think we should say anything about that given ou= r charter, which limits the work to SIP. That's opening up the question= as to how that will work, whether additional specification is required,etc= . =A0[/MB2]=A0


      =A0 =A0 Mino= r:

      =A0 =A0 --------

      =A0 =A0 1) General: I realize that at som= e point, someone changed all the
      =A0 =A0 terms to appear as formal names= - e..g., capitalized. Personally,
      =A0 =A0 I prefer just having the terms all lower case as I find it easier=A0 =A0 to read that way. However, the RFC editor leaves the choice to th= e
      =A0 =A0 document editor, but it needs to be consistent. So, another pa= ss
      =A0 =A0 is needed as I noticed a few that weren't caps that shoul= d be and
      =A0 =A0 some that were caps that shouldn't be. For example, in the
      = =A0 =A0 "Conceptually" paragraph I refer to above, "Renderer= " is in Caps,
      =A0 =A0 but it's not defined as a reserved word i= n the terminology and I'm
      =A0 =A0 assuming that the intent is to only have nouns in all caps? You
      = =A0 =A0 will find it awkward if you try to change every occurrence of the=A0 =A0 reserved words as sometimes it just won't read right (which i= s
      =A0 =A0 another reason to just use lower case).

      =A0 =A0 */[Duckworth, Mark] I don=92t care eit= her way. I think it was


      = =A0 =A0 Stephan who first suggested capitals, in the old terminology=

      =A0 =A0 document./*



      [MB] Again, either way is okay. But, there are some = places where it's not all caps. I also think using lower case is easier= just from a basic editing standpoint as it's more natural IMHO to just= type the words and not have to CAP. [/MB]

      [C= NG] It can be helpful to have capitalised terms to distinguish when you'= ;re talking about a entity Renderer vs a function "render".

      =A0 =A0 *//*



      =A0 =A0 2) Introduction: The t= ext in the intro (3rd para) (that I'm
      =A0 =A0 suggesting to move to = Motivation section) that starts with
      =A0 =A0 "Motivations" reads a little funky. I suggest to reword s= omething
      =A0 =A0 like:

      =A0 =A0 OLD:

      =A0 =A0 =A0 =A0Motivations for this document (and, in fact= , for the existence ofthe CLUE protocol) include:



      =A0 =A0 = NEW:

      =A0 =A0 =A0
      =A0 =A0 The motivations for the framework outli= ned in this document include the following:

      =A0 =A0 */[Duckworth, Mark] sounds good/*

      /*[CNG] OK*/


      =A0 = =A0 3) Introduction: List item (1). I was going to suggest rewording
      =A0= =A0 (as it reads as if the endpoints described are only specific to
      =A0 =A0 this document), but it's not clear to me exactly what that item= is
      =A0 =A0 trying to say. Can it be changed to something like the follo= wing
      =A0 =A0 and still mean what is intended? [As an aside "Media R= enderer"
      =A0 =A0 isn't a reserved word - I think perhaps if you add a definition=
      =A0 =A0 for "Renderer" that would help. I actually think that= 's probably
      =A0 =A0 necessary anyways as I think it's important = to distinguish "Media
      =A0 =A0 Renderer" from "Media Consumer"].

      =A0 =A0 OLD= :

      =A0 =A0 (1) Endpoints according to this document can, and usually = do, have multiple Media Captures and Media Renderers, that is, for example,= multiple cameras and screens. =A0While previous system designs were able to= set up calls that would light up all screens and cameras

      =A0 =A0 (or equivalent), what was missing was a mechanism that can asso= ciate the Media Captures with each other in space and time.

      =A0 =A0 = NEW:

      =A0 =A0 =A0
      =A0 =A0 (1) Endpoints in telepresence systems t= ypically have multiple Media Captures and Media Renderers, e.g., multiple c= ameras and screens. =A0While previous system designs were able to set up ca= lls that would capture media using all cameras and display media on all scr= eens, for example, there is no mechanism that can associate these Media Cap= tures with each other in space and time.

      =A0 =A0 =A0

      =A0 =A0 */[Duckworth, Mark] Yes, I think that says the i= ntent better./*

      /*[CNG] */I'd p= ropose a slight reword "Endpoints in telepresence systems typically ha= ve multiple Media Capture and Media Render devices, e.g., multiple cameras = and screens. ..."

      [MB2] That sounds good to me. [/MB= ]=A0

      = =A0

      =A0 =A0 =A0
      =A0 =A0 4) Section 4, last two paragraphs. I'm really wondering how muc= h
      =A0 =A0 needs to be said (if anything) about "legacy" in thi= s document.
      =A0 =A0 This document is defining what we need for CLUE. The= signaling
      =A0 =A0 solution document will of course get into how this works. But, I=A0 =A0 think we could just delete the next to last paragraph and condense=
      =A0 =A0 the one on RTP to reference the WG RTP mapping mapping document=

      =A0 =A0 */[Duck= worth, Mark] okay/*

      /*= [CNG] I don't think one paragraph describing this fall back in the fram= ework is too much. I think its helpful to explain fallback behaviour. */=

      [MB2] If you read it in the contex= t of that section, it doesn't quite seem to fit. It leaves more questio= ns than providing answers in my opinion. =A0 It seems to be some leftover t= ext from when the document had a lot more detail - e.g., the text about leg= acy devices is totally unnecessary as they aren't referenced elsewhere = in the framework any longer. =A0I think perhaps the idea of fallback when t= he device doesn't support CLUE can be stated much more concisely. =A0I = don't have a proposal right off, but will think about it. Unless someon= e else has suggestions. =A0[/MB2]


      =A0 =A0 5) S= omewhat General. There was a diagram in Section 5 in the -02
      =A0 =A0 ver= sion that was dropped in the -03. I really think that more
      =A0 =A0 diagr= ams would help to understand this stuff.

      =A0 =A0 */[Duckworth, Mark] That was the precu= rsor to this. The -02


      =A0 = =A0 diagram doesn=92t really say much, but I could try to update it. The=

      =A0 =A0 one below is a bit much to convert to = ASCII./*



      [MB] I can convert that to ascii art. I did all the diagr= ams in RFC 5239. This is just a tad more complicated than some of those. [/= MB]

      =A0 =A0 *//*

      =A0 =A0 *//*=



      =A0 = =A0 6) Per my other email, I believe these should all be normative
      =A0 = =A0 references and RFC 3264 needs to be added.

      [CNG] ???

      [MB2] Sorry, there= was another email exchange that I hadn't yet sent to the list about ma= king this document standards track and adding some more references. =A0I= 9;ll send that now. [/MB2]=A0

      _______________________________________________
      clue mailing list<= br> clue@ietf.org
      https= ://www.ietf.org/mailman/listinfo/clue

      =A0


      On Wed, Oct 2, 2013 at 9:45= AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:

      If you don=92t have a telepho= ne, you don=92t suddenly have a =93non-telephone=94, on which you make your= =93non-calls=94.

      [MB] CLUE isn't an endpoint - it's fu= nctionality supported by an endpoint. =A0So, non-CLUE means you don't s= upport the CLUE protocol or related processing to handle that protocol. [/M= B]=A0

      =A0

      You need to apply the negatio= n to the right word, and it is not CLUE that is subject to the negation.=

      =A0

      Keith

      =A0

      From: Mary Barnes [mailto:ma= ry.ietf.barnes@gmail.com]
      Sent: 02 October 2013 15:17<= br> To: DRAGE, Keith (Keith)
      Cc: Paul Coverdale; CLUE


      Subject: Re: [clue] Its not = "legacy", its ???
      <= u>

      =A0

      "non-CLUE enabled" means the endpoint does= not support the CLUE protocol (at all) or the endpoint is not using the CL= UE protocol for whatever reason (e.g., fallback case)

      =A0

      I think the "non-CLUE" is more in line wit= h the original implication of the term "legacy". =A0

      =A0

      Mary .

      =A0

      On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:

      Just to add a pedantic point,= I am not sure what a =93non-CLUE=94 is. What we have is something where CLUE does not exist, not the creation of some othe= r concept of a =93non-CLUE=94 to complement a =93CLUE=94. You want to apply= the negation to the =93enabled=94 which is something like =93disabled=94, = =93unenabled=94 or whatever.

      =A0

      Keith=

      =A0

      From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
      Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
      Cc: CLUE


      Subject: Re: [clue] Its not = "legacy", its ???

      =A0

      It is a fine line. =A0I personally have a preference= for "non-CLUE enabled". =A0 I really don't think we'll b= e using that in too many places in the documents that it's too much typing. = =A0If someone thinks that's the case, perhaps we use "clueless&quo= t; in the docs until we're ready to ship them out of the WG and then ju= st do a global change. =A0As I've said before for XCON, we do use the term "non-XCON enabled" which I think has the right sema= ntics and really isn't too much of a mouthful to say either.<= /u>

      =A0

      Mary.=A0

      =A0

      On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> wrote:<= /u>

      I thought the proposal of "clueless' was ju= st a joke when I first saw it,
      but apparently not.

      I think this term will just invite ridicule. It's a bit of a mouthful, = but I
      would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
      at least hyphenate it (clue-less).

      ...Paul


      >-----Original Message-----
      >From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

      >Paul Kyzivat
      >Sent: Tuesday, October 01, 2013 5:40 PM
      >To: clue@ietf.org
      >Subject: Re: [clue] Its not "legacy", its ???
      >

      >On 10/1/13 12:45 PM, Robert Hansen wrote:
      >> I am personally very fond of 'CLUEless' :)
      >
      >One of the reasons I liked the name "clue" for the wg was bec= ause it
      >gave us an excuse to use "clueless" and "clueful". = However they do have
      >the feel of "informal" usage - a bit odd for formal use. (But= I can get
      >over that.)
      >
      > =A0 =A0 =A0 Thanks,
      > =A0 =A0 =A0 Paul
      >
      >> Rob
      >>
      >> On 01/10/2013 17:22, Paul Kyzivat wrote:
      >>> Mary,
      >>>
      >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discu= ss what
      >>> word to use - that we could do that on the list.
      >>>
      >>> I agree with you, I also think "legacy" has the wron= g connotation for
      >>> what we mean, so I would like to find a better term. I have no= ideas
      >>> that I love, but a couple that I could live with: "non-cl= ue",
      >"clueless".
      >>>
      >>> =A0 =A0 =A0Thanks,
      >>> =A0 =A0 =A0Paul
      >>>
      >>> On 10/1/13 10:26 AM, Mary Barnes wrote:
      >>>> I'm in another meeting so unfortunately cannot attend = today. =A0But, I
      >>>> would really, really like to get away from the term "= legacy" - =A0the
      >>>> English language definition of "legacy" is not c= orrect. CLUE isn't
      >>>> superseding any functionality of current SIP endpoints. = =A0It's adding
      >>>> additional functionality. I would much rather select somet= hing like
      >>>> "non-Clue enabled endpoint". =A0 We can shorten = if folks are concerned
      >>>> about the length of a more appropriate alternative term. >>>>
      >>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
      >>>> slightly more appropriate since it's a different archi= tecture and
      >>>> entirely new application - i.e., it isn't based on RFC= 3261, but
      >>>> CLUE is, so any suggestion that it's replacing any cur= rent SIP
      >>>> functionality isn't correct.
      >>>>
      >>>> Regards,
      >>>> Mary.
      >>>>
      >>>>
      >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <      pkyzivat@alum.mit.edu
      >>>> <mailto:      pkyzivat@alum.mit.edu>> wrote:
      >>>>
      >>>> =A0 =A0 You can find Christer's slides for today at: >>>>
      >>>>

      >>>> /CLUE_Legacy_1oct13.pptx>
      >>>>
      >>>>
      >>>>
      >>>> =A0 =A0 See you shortly.
      >>>>
      >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
      >>>> =A0 =A0 _________________________________________________<= br> >>>> =A0 =A0 clue mailing list
      >>>> =A0 =A0 clue@ietf.org <mailto:clue@ietf.org>
      >>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue >>>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue&g= t;
      >>>>
      >>>>
      >>>
      >>> _______________________________________________
      >>> clue mailing list
      >>> clue@ietf.o= rg
      >>> https://www.ietf.org/mailman/listinfo/clue
      >>
      >> _______________________________________________
      >> clue mailing list
      >> clue@ietf.org
      >>       https://www.ietf.org/mailman/listinfo/clue
      >>
      >
      >_______________________________________________
      >clue mailing list
      >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

      _______________________________________________
      clue mailing list
      clue@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/clue

      =A0

      =A0



      --089e015375320d911404e8b39dd2-- From Christian.Groves@nteczone.com Mon Oct 14 16:48:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F921F8E51 for ; Mon, 14 Oct 2013 16:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsrrRSZ5VrXe for ; Mon, 14 Oct 2013 16:48:11 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id D038511E8122 for ; Mon, 14 Oct 2013 16:48:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUBAM+BXFJ20ckw/2dsb2JhbAANTIM/TMImgT6DGQEBAQMBAQEBJAsBBRsVBgkBAQUJAgsYCQwKCAcJAwIBAgEJDB8RBg0BBQIBAQWHdw0FqiyTPgSODYE5BwqEGwOUJ4UMlAuBXA Received: from ppp118-209-201-48.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.201.48]) by ipmail07.adl2.internode.on.net with ESMTP; 15 Oct 2013 10:17:58 +1030 Message-ID: <525C82AC.4050807@nteczone.com> Date: Tue, 15 Oct 2013 10:47:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Roberta Presta References: <20131008112031.25649.48885.idtracker@ietfa.amsl.com> <3EBFF01C-ABCD-46C8-A5B9-FA99C26CF705@unina.it> <52576D96.3050606@nteczone.com> <525BE333.2050206@unina.it> In-Reply-To: <525BE333.2050206@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 23:48:12 -0000 Hello Roberta, Thanks for the response. Please see my comments below. Regards, Christian On 14/10/2013 11:27 PM, Roberta Presta wrote: > Hello Christian, > > thank you for your comments. > Please see below. > > Il 11/10/2013 05:16, Christian Groves ha scritto: >> Hello Simon and Roberta, >> >> Thanks for the updates. I had a look and have a few comments below: >> >> 1. Sect.1 bullet 2 : The Config allows captures and encodings to be >> selected so I would propose to update the wording: >> 2. enabling a MC to request the desired > resulting> multimedia streams from the offering MP. > We have considered a stream as a capture encoding, i.e. the > association of a media capture and a capture encoding, as per the > framework definition of "stream". > We will recall such definition in section "Terminology". [CNG] I think in the protocol document rather than trying to shorten things by referring to "stream" we should be should talk about captures, encodings etc to be more precise. >> >> 2. Sect.3 1st para: The MC not only requests the stream but receives >> them. I propose updating the text: >> ...while the client side is represented by the Media Consumer, >> which requests the media streams. >> > OK. >> 3. Sect. 3 3rd para: Similar comment to 1 above. I propose rewording: >> The MC selects the desired streams coming from the MP >> by using... > Same considerations of point 1. >> >> 4. Sect. 3.x: The tables have "Type". Is this really needed as it is >> explained in the text. Plus 3.2 the message name is "Response" and >> the type is "Response". It seems superfluous. >> > The type of the message is an important characteristic. > Indeed, notifications, requests and responses are the three main > classes of CLUE messages. > A request is issued only by a MC to a MP, and each request expects a > response message coming from the opposite direction. > A notification (like the advertisement) is an asynchronous announce. > CLUE messages are demultiplexed in a CLUE endpoint on the basis of the > type of the message: > - A MC receives only responses and notifications, while it issues only > requests > - A MP receives only requests and issues responses and notifications [CNG] I don't see why a MP would not receive a "response"? > CLUE messages are expected to belong to one of the aforementioned > categories (and this is reflected in the schema definitions). > The draft definitely needs more text about it. [CNG] I don't understand what "demultiplexing" has to do with the type? I thought this would be done based on the message name? Why can't we follow a simple Request/Response type? The behaviour is based on the message name rather than another concept of "type" i.e. MP sends an Advertisement (req) it receives an response (ack/nack). MC sends a Configure (req) it receives an response (ack/nack). MC sends a Reavd (req) it receives a response (ack/nack) We don't need to call an "Advertisement" a notification because ultimately it doesn't mean anything. The MC reacts based on the semantic of Advertisement and the information elements included. > >> 5. Sect.3.3: Nit: Rescription should be "Description" >> > OK. >> 6. Sect 3.x: Are we missing a message? There is a Response for a >> Configure but there is no response to an Advertisement. If the MC >> receives an Advertisement there should at least be an indication that >> it was received OK. Why would a response to a Configure or an >> Advertisement be handled differently. I think the RE-ADV should only >> be used when the MC needs to refresh its state, not for indicating >> that there is a Advertisement message syntax problem, etc. Note: this >> is a similar comment as Paul's regarding the application level ACK. I >> don't think that a ADV needs an immediate CFG. >> > Currently in the draft there isn't a mechanism that acknowledge the ADV. > We have not considered acknowledge mechanisms at all and we have tried > to only rely on timeouts and retry mechanisms, i.e., if nothing > happens within the timeout interval and the timeout fires, then the > message is issued again. This is repeated until the max number of > retry is achieved. > We can discuss the introduction of acks for notification messages. An > acknowledgement mechanism should not be needed by the request-response > couples since the responses act as acks. > The READV functionality could be then reduced to the one of a simple > refresh request, since problems with the received ADV could be treated > otherwise. [CNG] Isn't there an acknowledgement mechanism for the Configure message? i.e. the response. I'm wondering why the mechanism is different for Advertisements? The MC is expected to do something at the reception of an Advertisement rather than just ignore it. Just a the MP is expected to do something when receiving the Configure. > >> 7. Sect.5 2nd para: What is meant by ".. if the number of trials is >> below the retry >> threshold...? >> > Explained in answer to point 6. We will correct the text in order to > make it clearer. >> 8. Sect.5 3rd para: As per 6 I think that rather than RE-ADV a >> "ADV-RESP" would be sent indicating an error condition. A MP should >> be the one to decide to determine if another ADV is sent. >> > I'm OK with decoupling the READV functionality from the problems with > a received ADV as per point 6. > >> 9. Sect.5 3rd para: This indicates that if there is an error with the >> ADV the MC goes from state "receive ADV" to "IDLE". What doesn't >> appeared to be covered is what happens if the MC is in "IN CALL" >> state when it receives the ADV and there's an error? I would assume >> that rather than go to IDLE on error that it would go back to "IN >> CALL"? The state could potentially be affected by what error is >> received. > > The IN CALL state indicates that the media streams the MP and the MC > have agreed on (and are aware of) the media streams to be exchanged > within the call. > When a MC/MP goes out from the IN CALL state it means that something > has changed and that the media streams currently exchanged may not be > aligned with the ones known at the CLUE level. > For example, if a MP stops sending a certain media stream for any > reason, it issues a new advertisement to the MC after such change. [CNG] I understand the need for re-Advertisement but one doesn't necessary change the current media state. A re-advertisement may also advertise a new VC for a camera that has been turned on. To me the media is still "IN CALL". > Once received the ADV, the MC then flows from the IN CALL state to the > ADV RECEIVED one and, if there are problems with the ADV, moves back > to the IDLE state, which is a state where MP and MC are not aligned > with the streams actually involved in the conference. It does not mean > that there are no streams currently exchanged between the peers. >> >> 10. Sect.5 General: The term "CALL" is used. For me this encompasses >> the entire session. i.e. to be "IN CALL" it would assume the CLUE >> negotiation is done, the media streams are configured and media is >> flowing etc. As this is describing a CLUE state machine should we >> instead use CLUE specific terminology? i.e. "IN CALL" -> "CAPTURES >> NEGOTIATED" etc. >> > The IN CALL state can be seen as a "negotiation completed" state where > both the CLUE parties have successfully agreed on the media streams to > be exchanged at the CLUE level. > We could change the name of the state or alternatively add more text > to clarify the concept. [CNG] I think we need to do both. I don't think "IN CALL" accurately reflects what the state is. > >> 11. Sect. 6 General: As per 6 above I think there should be an >> application level response, either saying success or error. Once that >> is received then it should wait for a CONFIG or RE-ADV. >> > See point 6 answer. >> 12 Sect. 6 Para.5: As per 9 above. If the MP receives a CONFIG that >> has error when it is an a IN CALL state I would expect that it remain >> in an in call state. Rather than go back to IDLE. >> > See point 9 answer. >> 13 General: Do we need to define the scope of the states that they >> only cover CLUE? or do they have further scope. E.g. If the CLUE >> state is Terminated does this indicate some other behaviour that the >> MP or MC should do? i.e. send updated SIP O/A to remove media. Btw, >> I'm not suggesting this extended scope. >> > I think it is still premature in this phase. [CNG] What do the states currently reflect? For example I don't think "IN CALL" is correct from a CLUE perspective because CLUE doesn't consider calls. However if you think that the states will cover SIP O/A then its a different matter. > ..snip.. >> 18 Sect 8.1 para 4: It mentions here that " Elements or attributes >> from unknown namespaces MUST be ignored". If the MP or MC receives >> such an element I would expect that an error be returned to the ADV >> or CFG message it contained or? > We have conceived an extensions negotiation mechanism (via the OPTIONS > request/response message) that should avoid to fall into that > situation (i.e. when a peer sends a message with xml elements coming > from unknown namespaces). > However, extensions as elements placed in correspondence of are > typically conceived to indicate something more than the basic behavior > of the CLUE negotiation. > If the other part is not able to understand that "something more", it > does nothing less than the ordinary behavior. [CNG] I understand the error situation, its the "ordinary" behaviour part that's a concern. If the MC and MP receives something that it doesn't understand I would have thought it would generate an error response rather than ignoring it. >> >> 19 Sect 8.1: I guess each of the last 3 bullets should be possible >> depending on the type of data. I think that we need to separate the >> actual syntax and structures (i.e. CS, CSEs, STSs etc) from the >> Captures attributes. It should be possible to create new attributes >> or update their value through an extension mechanism rather than need >> to update the protocol version. Is this what is meant by the 3rd >> bullet? Updates to the syntax and structures should need a new version. >> > Yes, the third bullet refers to a mechanism that enables to create new > attributes without update the data model schema version and preserving > the compatibility with it. > However, according to that possibility, new attributes should be > defined elsewhere and also in this case the new schema should be > linked wherever we want to exploit that extension. [CNG] I guess my point is that there are multiple ways of providing extensions but should we allow all those methods to be used. Can we specify that if you want to add a new message then this is the one way to do it. If you want to add new syntax this is the way to do it. We can add all sorts of flexibility but is it needed? >> 19 Sect 8.2: I think a new message does need a new version so this >> should be the ONLY chance. > As per the OPTIONS mechanism we are able to handle both data model and > protocol updates. > In that vision, there are stable protocol and data model versions > (with associated schema files), and extensions defined in other XML > schemas. > Let's say that we have: > 1) an extension for the data model, i.e. a schema file S1 defining new > data model elements. For example, we can imagine a schema defining > other audio capture attributes represented by XML elements placed in > correspondence of the element in the data model audio capture > definition. > 2) an extension for the protocol, i.e. a schema file S2 defining for > example a new notification message that makes the MP able to inform > the MC about the availabilty and the status of video captures only. > The MC supporting both extensions issues an OPTIONS containing the > references of both S1 and S2. > The MP supporting both extensions recognizes the schemas and then > knows that it can issue specific notifications according to the format > provided in S2 and that it can use also the features defined in S1 to > describe the available audio captures. [CNG] See above. > >> ..snip.. > >> 22 Sect 9: Why is the MC responsible for sending the OPTIONS message? >> I would have thought that as the MP sends the ADV (which is >> effectively the first message) that it would send it? >> > With the introduction of the OPTIONS message, the ADV is no more the > first message to be sent. [CNG] The ADV is effectively the first message with real information related to what CLUE is about, sharing information about captures. > The state machines represent the evolution of the MP and of the MC > after that the version of the protocol and the involved extensions > have been agreed with the OPTIONS message. > The OPTIONS message is conceived as a request that expects a response. [CNG] I agree that OPTIONs needs a response. Like all the other CLUE messages. > > It is the MC that issues that request, providing to the MP the > supported extensions and the higher supported protocol version. In > that way, the MP can select the extensions in the set supported by the > MC and then use only information that is understood by the MC. [CNG] Doesn't think require effectively 3 messages? OPTIONS->RESPONSE->ACK for the MP to be sure what to send? If the MP sends OPTIONS and gets a response from the MC it then knows what to send in the ADV. The negotiation still works because the MC selects from what the MP can send. > > Roberta > >> Regards, Christian >> >> On 8/10/2013 10:21 PM, Simon Pietro Romano wrote: >>> ...here it is. >>> >>> Simon >>> >>> Inizio messaggio inoltrato: >>> >>>> *Da: *internet-drafts@ietf.org >>>> *Oggetto: **New Version Notification for >>>> draft-presta-clue-protocol-02.txt* >>>> *Data: *08 ottobre 2013 13:20:31 GMT+02:00 >>>> *A: *Roberta Presta >>> >, Simon Pietro Romano >>>> >, Simon Romano >>>> > >>>> >>>> >>>> A new version of I-D, draft-presta-clue-protocol-02.txt >>>> has been successfully submitted by Roberta Presta and posted to the >>>> IETF repository. >>>> >>>> Filename:draft-presta-clue-protocol >>>> Revision:02 >>>> Title:CLUE protocol >>>> Creation date:2013-10-08 >>>> Group:Individual Submission >>>> Number of pages: 26 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-02.txt >>>> Status: http://datatracker.ietf.org/doc/draft-presta-clue-protocol >>>> Htmlized: http://tools.ietf.org/html/draft-presta-clue-protocol-02 >>>> Diff: http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-02 >>>> >>>> Abstract: >>>> The CLUE protocol is an application protocol conceived for the >>>> description and negotiation of a CLUE telepresence session. The >>>> design of the CLUE protocol takes into account the requirements and >>>> the framework defined, respectively, in [I-D.ietf-clue-framework] >>>> and >>>> [I-D.ietf-clue-telepresence-requirements]. The companion document >>>> [I-D.kyzivat-clue-signaling] delves into CLUE signaling details, as >>>> well as on the SIP/SDP session establishment phase. We herein focus >>>> on the application level perspective. Message details, together >>>> with >>>> the behavior of both the Media Provider and the Media Consumer are >>>> discussed. >>>> >>>> >>>> >>>> >>>> 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 >>>> . >>>> >>>> The IETF Secretariat >>>> >>>> >>> >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>> >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From christer.holmberg@ericsson.com Tue Oct 15 11:09:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB111E8181 for ; Tue, 15 Oct 2013 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.72 X-Spam-Level: X-Spam-Status: No, score=-5.72 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ia1MqRcnV3FV for ; Tue, 15 Oct 2013 11:09:33 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68DFB11E81F0 for ; Tue, 15 Oct 2013 11:09:27 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-81-525d84d6f232 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 17.F6.03802.6D48D525; Tue, 15 Oct 2013 20:09:26 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Tue, 15 Oct 2013 20:09:25 +0200 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Design team meeting: Out of battery Thread-Index: Ac7J0a6vU2TcbtZ9RniGZRJESrox1Q== Date: Tue, 15 Oct 2013 18:09:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4BEFA4@ESESSMB209.ericsson.se> References: <49E45C59CA48264997FEBFB29B6BC2D60379FF86@CRPMBOXPRD07.polycom.com>, <525B5F6A.1000506@nteczone.com> In-Reply-To: <525B5F6A.1000506@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4BEFA4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre61ltggg423hSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK7FrewF6wUqXjzsZ29gXM/XxcjJISFgItHatJ4dwhaTuHBv PRuILSRwmFFi2WaxLkYuIHsJo8TGppdACQ4ONgELie5/2iA1IgLKEkc394PVCwvoSFxdcoQF Im4o0T+lmwnC1pNo3tENFmcRUJU49Wk/2C5eAV+JG61TGSF25Uu8f/YArIYTaM6jzs/MIDYj 0D3fT60Bm8MsIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaS+LHhEgtEfb7EpLsToHYJSpyc +YRlAqPILCSjZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQtq7EjH+HoGqsJf7faGRGVrOAkWMV I3tuYmZOernRJkZg9Bzc8lt1B+OdcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwOjx4YebW83fyKRaP4t/tutv/lTadVSYO1TnnMa7K/f8o/vDHSbfvVnm+2fJ95Lf F2rEFVY/1fj54nGo8L3k3zExB2x6El9Ip3wPn53UwJkYp5IX9WWh1CL/MzXLCqfzp2d97b2i /qrrlb+8V3/nxcXiuW0zG35lzNjCcfeN2KOetPXxtyQWuyuxFGckGmoxFxUnAgAe+/zGbAIA AA== Subject: [clue] Design team meeting: Out of battery X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 18:09:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4BEFA4ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I appologize for suddenly leaving the design team meeting today. My mobile ran out of battery, and as I was driving I wasn't able to charge = it. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4BEFA4ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2198E10480226B459B4725779AEF7AD5@ericsson.com> Content-Transfer-Encoding: quoted-printable

      Hi,

       

      I appologize for sudde= nly leaving the design team meeting today.

       

      My mobile ran out of b= attery, and as I was driving I wasn't able to charge it.

       

      Regards,=

       

      Christer=

      --_000_7594FB04B1934943A5C02806D1A2204B1C4BEFA4ESESSMB209erics_-- From mary.ietf.barnes@gmail.com Tue Oct 15 15:47:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A324921F9CFB for ; Tue, 15 Oct 2013 15:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.576 X-Spam-Level: X-Spam-Status: No, score=-101.576 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL8V5myDGkX3 for ; Tue, 15 Oct 2013 15:47:57 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5068221F999C for ; Tue, 15 Oct 2013 15:47:57 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id cy11so6874294qeb.26 for ; Tue, 15 Oct 2013 15:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bnTs18Sm8vag63SG0mjxUvRKGrUbuX6OR1QS0NqkExo=; b=Y+sC9ol+iCdGV+hNL2WF4JBlKSBzS+3SMAYt/kVqLG8q0Sw6iSQHXidD201rnY1Xlz YZNkNZJiHP9bjBJJd5xtiEtrXwBgI21qzhT/nF20Cse6NIcon7nnN7asySq3RlR8E29C FH/lgcy814TG53Y/rKb3FmsuEYn6pLvzl2KfX141tHnTvySxOC9gaST7XC7Aevl97NGt XTR2nGoWsT6opOCn/WGof4XO9AT+lFZ8OwV5OepQoNTqyUXy9ckXn1C6VuuuOGKji7N9 4PnO4qmJnSZ4TGJ3+gwtaXxKY5Xqu5w8p9Ywq+Wwp9Znmd49i1ZqvmvGxpEuDz6RqCiH n7Xg== MIME-Version: 1.0 X-Received: by 10.224.165.129 with SMTP id i1mr378556qay.114.1381877276654; Tue, 15 Oct 2013 15:47:56 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Tue, 15 Oct 2013 15:47:56 -0700 (PDT) In-Reply-To: <52573B92.4050801@nteczone.com> References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> Date: Tue, 15 Oct 2013 17:47:56 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e0158b11e32c2cb04e8cf6029 Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:47:58 -0000 --089e0158b11e32c2cb04e8cf6029 Content-Type: text/plain; charset=ISO-8859-1 Christian, One last response below [MB3]. Mary. On Thu, Oct 10, 2013 at 6:43 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > ..snip.. > > >> >> NEW: >> The purpose of this document is to describe the >> requirements for a >> specification that enables interworking between different >> SIP-based >> [RFC3261] telepresence systems by exchanging and negotiating >> appropriate information. In the context of these >> requirements and related >> solutions, the SIP telepresence systems are expected to >> support the SIP conferencing >> framework [RFC 4353] and SIP based conference control [RFC >> 4579] . >> >> >> [CNG] I don't agree that it is expected that telepresence systems >> support RFC4353 and 4579. CLUE should be able to be used without >> these. Especially in the case of point to point CLUE calls. The >> use of RFC4353 and RFC4579 shouldn't be precluded however. >> >> [MB2] I would agree for a point to point, so we adjust the wording to >> accommodate that. However, our WG is explicitly chartered to be based on >> SIP Conferencing. Text from the charter: >> " WG will create specifications for SIP-based conferencing systems" >> I would suggest the following new text to be explicit about point to >> point. >> NEW: >> The purpose of this document is to describe the requirements for a >> specification that enables interworking between different SIP-based >> [RFC3261] telepresence systems and endpoints by exchanging and >> negotiating >> appropriate information. In the context of the requirements in this >> document and >> related solution documents, this includes both point to point SIP >> sessions as well as SIP based >> conferences as described in the SIP conferencing >> framework [RFC 4353] and the SIP based conference control [RFC 4579] >> specifications. >> >> It is important for you to be aware that 4353 is informational, however, >> 4579 is a BCP, thus it should be supported. >> [/MB2] >> > > [CNG] I'm happy with your suggestion, it covers the point to point case > and removes "expected to support". > > > >> * about dictating architectural choices >> In the Introduction section, "/It is not the intention >> of CLUE >> >> to dictate telepresence architectural and implementation >> choices./" I would propose to erase "architectural >> choice" and >> >> to leave only "implementation choice". The CLUE framework >> should provide some reference architecture for SIP-based >> telepresence systems in order to let them >> interoperate, so I >> would not say that CLUE is not intended to dictate >> architectural choice. >> >> [MB] I agree. [/MB] >> >> >> [CNG] I would prefer to leave the existing text. I believe that >> was the original intention. >> >> [MB] I don't know what you mean by "original intention"? We have a WG >> deliverable for a framework which does introduce some architectural >> concepts. Clearly, we aren't prescribing implementation choices. But, we >> do lay out a model/architecture/framework for the solution. I think we >> should stick with the text that the majority agrees with. Also, please keep >> in mind that this is an informational document, thus it's setting the >> context for the solution, but defines nothing normative per se. >> [/MB] >> > > [CNG] By original intention I mean the original text "It is not the > intention of CLUE to dictate telepresence architectural and implementation > choices." This is the current text we have "stuck" to. The change isn't > just about removing "architectural" from the requirements its also the > suggested change to the framework. The current framework document describes > a framework for a "protocol" not an overall architectural description of a > SIP telepresence system. I think there's enough in the framework rather > than adding a discussion on overall SIP telepresence system architecture. > That work would be non-trivial. > [MB3] Right and removing "architectural" from the sentence is not at all the same thing as saying that CLUE will define an "overall SIP telepresence system architecture". The term "architectural choice" really doesn't mean anything specific, so by saying we are not doing that, it provides no information as to what CLUE isn't doing nor does it result in this document stating that CLUE is making architectural choices. However, some of us would interpret architectural choices to be what protocols one uses and what functional entities use the protocols and how they use those protocols. That is very close to what we are doing with the framework. And, as a matter of fact, that's very much what the term "architecture" means in the context of IETF - e.g., The Internet Architecture Board (IAB): http://www.iab.org/about/iab-overview/ [/MB3] > >> ..snip.. >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> > --089e0158b11e32c2cb04e8cf6029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      Christian,

      One last response below [MB3= ].

      Mary.


      On Thu, Oct 10, 2013 at 6:43 PM, Christian Groves <= span dir=3D"ltr"><Christian.Groves@nteczone.com> wrote:
      Hello Mary,
      ..snip..



      =A0 =A0 =A0 =A0 NEW:
      =A0 =A0 =A0 =A0 =A0 =A0The purpose of this document is to describe the
      =A0 =A0 =A0 =A0 requirements for a
      =A0 =A0 =A0 =A0 =A0 =A0specification that enables interworking between diff= erent
      =A0 =A0 =A0 =A0 SIP-based
      =A0 =A0 =A0 =A0 =A0 =A0[RFC3261] telepresence systems by exchanging and neg= otiating
      =A0 =A0 =A0 =A0 =A0 =A0appropriate information. =A0In the context of these<= br> =A0 =A0 =A0 =A0 requirements and related
      =A0 =A0 =A0 =A0 =A0 =A0solutions, the SIP telepresence systems are expected= to
      =A0 =A0 =A0 =A0 support the SIP conferencing
      =A0 =A0 =A0 =A0 =A0 =A0framework [RFC 4353] and SIP based conference contro= l [RFC
      =A0 =A0 =A0 =A0 4579] .


      =A0 =A0 [CNG] I don't agree that it is expected that telepresence syste= ms
      =A0 =A0 support RFC4353 and 4579. CLUE should be able to be used without =A0 =A0 these. Especially in the case of point to point CLUE calls. The
      =A0 =A0 use of RFC4353 and RFC4579 shouldn't be precluded however.

      [MB2] I would agree for a point to point, so we adjust the wording to accom= modate that. =A0However, our WG is explicitly chartered to be based on SIP = Conferencing. =A0Text from the charter:
      =A0" WG will create specifications for SIP-based conferencing systems&= quot;
      I would suggest the following new text to be explicit about point to point.=
      NEW:
      =A0 =A0The purpose of this document is to describe the requirements for a =A0 =A0specification that enables interworking between different SIP-based<= br> =A0 =A0[RFC3261] telepresence systems and endpoints by exchanging and negot= iating
      =A0 =A0appropriate information. =A0In the context of the requirements in th= is document and
      =A0 =A0related solution documents, =A0this includes both point to point SIP= sessions as well as SIP based
      =A0conferences as described in the SIP conferencing
      =A0 =A0framework [RFC 4353] and the SIP based conference control [RFC 4579]= specifications.

      It is important for you to be aware that 4353 is informational, however, 45= 79 is a BCP, thus it should be supported.
      [/MB2]

      [CNG] I'm happy with your suggestion, it covers the point to point case= and removes "expected to support".



      =A0 =A0 =A0 =A0 =A0 =A0 =A0 * about dictating architectural choices
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In the Introduction section, "/It is n= ot the intention
      =A0 =A0 =A0 =A0 of CLUE

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to dictate telepresence architectural and i= mplementation
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 choices./" I would propose to erase &q= uot;architectural
      =A0 =A0 =A0 =A0 choice" and

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to leave only "implementation choice&q= uot;. The CLUE framework
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should provide some reference architecture = for SIP-based
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 telepresence systems in order to let them =A0 =A0 =A0 =A0 interoperate, so I
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 would not say that CLUE is not intended to = dictate
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 architectural choice.

      =A0 =A0 =A0 =A0 [MB] I agree. [/MB]


      =A0 =A0 [CNG] I would prefer to leave the existing text. I believe that
      =A0 =A0 was the original intention.

      [MB] I don't know what you mean by "original intention"? =A0 = =A0 We have a WG deliverable for a framework which does introduce some arch= itectural concepts. =A0Clearly, we aren't prescribing implementation ch= oices. =A0But, we do lay out a model/architecture/framework for the solutio= n. =A0I think we should stick with the text that the majority agrees with. = Also, please keep in mind that this is an informational document, thus it&#= 39;s setting the context for the solution, but defines nothing normative pe= r se.
      [/MB]

      [CNG] By original intention I mean the original text "It is not the in= tention of CLUE to dictate telepresence architectural and implementation ch= oices." This is the current text we have "stuck" to. The cha= nge isn't just about removing "architectural" from the requir= ements its also the suggested change to the framework. The current framewor= k document describes a framework for a "protocol" not an overall = architectural description of a SIP telepresence system. I think there's= enough in the framework rather than adding a discussion on overall SIP tel= epresence system architecture. That work would be non-trivial.
      [MB3] Right and removing "architectural" = from the sentence is not at all the same thing as saying that CLUE will def= ine an "overall SIP telepresence system architecture". =A0The ter= m "architectural choice" really doesn't mean anything specifi= c, so by saying we are not doing that, it provides no information as to wha= t CLUE isn't doing nor does it result in this document stating that CLU= E is making architectural choices. =A0 However, some of us would interpret = architectural choices to be what protocols one uses and what functional ent= ities use the protocols and how they use those protocols. =A0That is very c= lose to what we are doing with the framework. And, as a matter of fact, tha= t's very much what the term "architecture" means in the conte= xt of IETF - e.g., The Internet Architecture Board (IAB): =A0http://www.iab.org/about/iab-overview/=
      [/MB3]

      =A0 =A0 ..snip..


      =A0 =A0 _______________________________________________
      =A0 =A0 clue mailing list
      =A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
      =A0 =A0 https://www.ietf.org/mailman/listinfo/clue




      --089e0158b11e32c2cb04e8cf6029-- From Christian.Groves@nteczone.com Tue Oct 15 17:21:50 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218BD21F9BD5 for ; Tue, 15 Oct 2013 17:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFIE96dbjcEk for ; Tue, 15 Oct 2013 17:21:49 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id D260F21F9B25 for ; Tue, 15 Oct 2013 17:21:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAH3bXVJ20fmO/2dsb2JhbAANTYM/wnyBOYMaAQEEAQEBNRsbCgEQCxIPFggHCQMCAQIBFR8DDgYNAQUCAQEFEod3qlWTPo1/gUsHhCUDlCeZF4FT Received: from ppp118-209-249-142.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.249.142]) by ipmail05.adl6.internode.on.net with ESMTP; 16 Oct 2013 10:51:47 +1030 Message-ID: <525DDC15.1040807@nteczone.com> Date: Wed, 16 Oct 2013 11:21:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mary Barnes References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:21:50 -0000 Hello Mary, Please see below. Regards, Christian > > > > * about dictating architectural choices > In the Introduction section, "/It is not the > intention > of CLUE > > to dictate telepresence architectural and > implementation > choices./" I would propose to erase "architectural > choice" and > > to leave only "implementation choice". The > CLUE framework > should provide some reference architecture for > SIP-based > telepresence systems in order to let them > interoperate, so I > would not say that CLUE is not intended to dictate > architectural choice. > > [MB] I agree. [/MB] > > > [CNG] I would prefer to leave the existing text. I believe > that > was the original intention. > > [MB] I don't know what you mean by "original intention"? > We have a WG deliverable for a framework which does introduce > some architectural concepts. Clearly, we aren't prescribing > implementation choices. But, we do lay out a > model/architecture/framework for the solution. I think we > should stick with the text that the majority agrees with. > Also, please keep in mind that this is an informational > document, thus it's setting the context for the solution, but > defines nothing normative per se. > [/MB] > > > [CNG] By original intention I mean the original text "It is not > the intention of CLUE to dictate telepresence architectural and > implementation choices." This is the current text we have "stuck" > to. The change isn't just about removing "architectural" from the > requirements its also the suggested change to the framework. The > current framework document describes a framework for a "protocol" > not an overall architectural description of a SIP telepresence > system. I think there's enough in the framework rather than adding > a discussion on overall SIP telepresence system architecture. That > work would be non-trivial. > > [MB3] Right and removing "architectural" from the sentence is not at > all the same thing as saying that CLUE will define an "overall SIP > telepresence system architecture". The term "architectural choice" > really doesn't mean anything specific, so by saying we are not doing > that, it provides no information as to what CLUE isn't doing nor does > it result in this document stating that CLUE is making architectural > choices. However, some of us would interpret architectural choices > to be what protocols one uses and what functional entities use the > protocols and how they use those protocols. That is very close to > what we are doing with the framework. And, as a matter of fact, that's > very much what the term "architecture" means in the context of IETF - > e.g., The Internet Architecture Board (IAB): > http://www.iab.org/about/iab-overview/ > [/MB3] [CNG] I'm not sure what the IAB has to do with CLUE but... I think its an issue of the scope of the "architecture." As I mentioned above its not so much the deletion of a word its what is intended by that. The following sentence was "the CLUE framework should provide some reference architecture for SIP-based telepresence systems in order to let them interoperate" which you agreed to. I have an issue if the framework becomes a general document for describing a SIP telepresence system architecture. For a telepresence system there is functionality beyond CLUE. If it simply describes the architecture of how CLUE relates to SIP/SDP/RTP then I would agree that is in the scope of the framework document. I don't think it should be a general architecture of all the protocols/interface that a SIP Telepresence system may use. With respect to the issue of "saying what we are not doing" then we may as well remove the text regarding implementation choice. > > ..snip.. > > > _______________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > From mary.ietf.barnes@gmail.com Wed Oct 16 04:42:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E952A21F9DCF for ; Wed, 16 Oct 2013 04:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.553 X-Spam-Level: X-Spam-Status: No, score=-101.553 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOYH8Iwo4KDC for ; Wed, 16 Oct 2013 04:42:19 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7221F9D94 for ; Wed, 16 Oct 2013 04:42:18 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f11so4418567qae.0 for ; Wed, 16 Oct 2013 04:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g9Ede8sflV3ccuBfcspRa9EdUEi6EMXCuN1o8jKWx40=; b=BKZ4+yTtNEQABrf0CGjIA0RsVf0nIXd5Op3nQHiLcasEughuExfzPiDMCgaGmp5p+i IsUiHZZvcEf4kS9ocinxAwdCN+q4jsPgG/RijCboST4EFIuESSQJhNq+9bTY43dro0uj QcKKlWwU765a+EMxy/fExQ2A7kd8b73KxMReLssRVJit78vFqoVDt3fwpZArnNO/CiuJ IJug1cbU2Cwc7k13puqC0XlJzhz9ASURC40h7BGEhPE4BDRLswD0nzzAvjw5BxpEMDXH vpZK3Yv85RPiqn0DJdzg6gvLhtksxFK4GC6CGEmeIpWlDRzCBrkSbovZXIAZHmpJ+B70 6vUA== MIME-Version: 1.0 X-Received: by 10.229.64.66 with SMTP id d2mr3095229qci.4.1381923738316; Wed, 16 Oct 2013 04:42:18 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Wed, 16 Oct 2013 04:42:18 -0700 (PDT) In-Reply-To: <525DDC15.1040807@nteczone.com> References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> Date: Wed, 16 Oct 2013 06:42:18 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c1f2aa8773e404e8da3194 Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 11:42:20 -0000 --001a11c1f2aa8773e404e8da3194 Content-Type: text/plain; charset=ISO-8859-1 Yet another round of responses below [MB4]. I would like to hear if there's anyone else that shares Christian's concerns. If not, then I will leave the text with the change based on Roberta's input, which seems reasonable to me as the document editor. Thanks, Mary. On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > Please see below. > > Regards, Christian > > > >> >> >> * about dictating architectural choices >> In the Introduction section, "/It is not the >> intention >> of CLUE >> >> to dictate telepresence architectural and >> implementation >> choices./" I would propose to erase "architectural >> choice" and >> >> to leave only "implementation choice". The >> CLUE framework >> should provide some reference architecture for >> SIP-based >> telepresence systems in order to let them >> interoperate, so I >> would not say that CLUE is not intended to dictate >> architectural choice. >> >> [MB] I agree. [/MB] >> >> >> [CNG] I would prefer to leave the existing text. I believe >> that >> was the original intention. >> >> [MB] I don't know what you mean by "original intention"? >> We have a WG deliverable for a framework which does introduce >> some architectural concepts. Clearly, we aren't prescribing >> implementation choices. But, we do lay out a >> model/architecture/framework for the solution. I think we >> should stick with the text that the majority agrees with. >> Also, please keep in mind that this is an informational >> document, thus it's setting the context for the solution, but >> defines nothing normative per se. >> [/MB] >> >> >> [CNG] By original intention I mean the original text "It is not >> the intention of CLUE to dictate telepresence architectural and >> implementation choices." This is the current text we have "stuck" >> to. The change isn't just about removing "architectural" from the >> requirements its also the suggested change to the framework. The >> current framework document describes a framework for a "protocol" >> not an overall architectural description of a SIP telepresence >> system. I think there's enough in the framework rather than adding >> a discussion on overall SIP telepresence system architecture. That >> work would be non-trivial. >> >> [MB3] Right and removing "architectural" from the sentence is not at all >> the same thing as saying that CLUE will define an "overall SIP telepresence >> system architecture". The term "architectural choice" really doesn't mean >> anything specific, so by saying we are not doing that, it provides no >> information as to what CLUE isn't doing nor does it result in this document >> stating that CLUE is making architectural choices. However, some of us >> would interpret architectural choices to be what protocols one uses and >> what functional entities use the protocols and how they use those >> protocols. That is very close to what we are doing with the framework. >> And, as a matter of fact, that's very much what the term "architecture" >> means in the context of IETF - e.g., The Internet Architecture Board (IAB): >> http://www.iab.org/about/iab-**overview/ >> [/MB3] >> > [CNG] I'm not sure what the IAB has to do with CLUE but... I think its an > issue of the scope of the "architecture." [MB4] I was referencing the IAB's use of the term "architecture" - follow the link and see the context in which the term is used in the IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG to discuss architectures. [/MB4] As I mentioned above its not so much the deletion of a word its what is > intended by that. The following sentence was "the CLUE framework should > provide some reference architecture for SIP-based telepresence systems in > order to let them interoperate" which you agreed to. I have an issue if the > framework becomes a general document for describing a SIP telepresence > system architecture. For a telepresence system there is functionality > beyond CLUE. > [MB4] I think you are reading way too much into the text in this section of the document. It's intended to set the context and has no normative impact on anything that CLUE is doing. It's introductory text. [/MB4] > > If it simply describes the architecture of how CLUE relates to SIP/SDP/RTP > then I would agree that is in the scope of the framework document. I don't > think it should be a general architecture of all the protocols/interface > that a SIP Telepresence system may use. > > With respect to the issue of "saying what we are not doing" then we may as > well remove the text regarding implementation choice. > [MB4] I think the reference to "implementation" choice is important in that it's highlighting the fact that you can make telepresence systems interoperable without having to entirely impact a product design. As you note we are not designing an entire system. [/MB4] > > > >> ..snip.. >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> >> > --001a11c1f2aa8773e404e8da3194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      Yet another round of responses below [MB4]. =A0= I would like to hear if there's anyone else that shares Christian'= s concerns. =A0If not, then I will leave the text with the change based on = Roberta's input, which seems reasonable to me as the document editor.

      Thanks,
      Mary.=A0
      =


      On = Tue, Oct 15, 2013 at 7:21 PM, Christian Groves <Christian.Grov= es@nteczone.com> wrote:
      Hello Mary,

      Please see below.

      Regards, Christian





      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * about dictating architectural= choices
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 In the Introduction section= , "/It is not the
      =A0 =A0 =A0 =A0 intention
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of CLUE

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to dictate telepresence arc= hitectural and
      =A0 =A0 =A0 =A0 implementation
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 choices./" I would pro= pose to erase "architectural
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 choice" and

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to leave only "impleme= ntation choice". The
      =A0 =A0 =A0 =A0 CLUE framework
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 should provide some referen= ce architecture for
      =A0 =A0 =A0 =A0 SIP-based
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 telepresence systems in ord= er to let them
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 interoperate, so I
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 would not say that CLUE is = not intended to dictate
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 architectural choice.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [MB] I agree. [/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 [CNG] I would prefer to leave the existing text. I = believe
      =A0 =A0 =A0 =A0 that
      =A0 =A0 =A0 =A0 =A0 =A0 was the original intention.

      =A0 =A0 =A0 =A0 [MB] I don't know what you mean by "original inten= tion"? =A0 =A0 =A0 =A0 =A0 =A0We have a WG deliverable for a framework= which does introduce
      =A0 =A0 =A0 =A0 some architectural concepts. =A0Clearly, we aren't pres= cribing
      =A0 =A0 =A0 =A0 implementation choices. =A0But, we do lay out a
      =A0 =A0 =A0 =A0 model/architecture/framework for the solution. =A0I think w= e
      =A0 =A0 =A0 =A0 should stick with the text that the majority agrees with. =A0 =A0 =A0 =A0 Also, please keep in mind that this is an informational
      =A0 =A0 =A0 =A0 document, thus it's setting the context for the solutio= n, but
      =A0 =A0 =A0 =A0 defines nothing normative per se.
      =A0 =A0 =A0 =A0 [/MB]


      =A0 =A0 [CNG] By original intention I mean the original text "It is no= t
      =A0 =A0 the intention of CLUE to dictate telepresence architectural and
      =A0 =A0 implementation choices." This is the current text we have &quo= t;stuck"
      =A0 =A0 to. The change isn't just about removing "architectural&qu= ot; from the
      =A0 =A0 requirements its also the suggested change to the framework. The =A0 =A0 current framework document describes a framework for a "protoc= ol"
      =A0 =A0 not an overall architectural description of a SIP telepresence
      =A0 =A0 system. I think there's enough in the framework rather than add= ing
      =A0 =A0 a discussion on overall SIP telepresence system architecture. That<= br> =A0 =A0 work would be non-trivial.

      [MB3] Right and removing "architectural" from the sentence is not= at all the same thing as saying that CLUE will define an "overall SIP= telepresence system architecture". =A0The term "architectural ch= oice" really doesn't mean anything specific, so by saying we are n= ot doing that, it provides no information as to what CLUE isn't doing n= or does it result in this document stating that CLUE is making architectura= l choices. =A0 However, some of us would interpret architectural choices to= be what protocols one uses and what functional entities use the protocols = and how they use those protocols. =A0That is very close to what we are doin= g with the framework. And, as a matter of fact, that's very much what t= he term "architecture" means in the context of IETF - e.g., The I= nternet Architecture Board (IAB): http://www.iab.org/about/iab-overview/
      [/MB3]
      [CNG] I'm not sure what the IAB has to do with CLUE but... I think its = an issue of the scope of the "architecture."


      As I mentioned above i= ts not so much the deletion of a word its what is intended by that. The fol= lowing sentence was "the CLUE framework should provide some reference = architecture for SIP-based telepresence systems in order to let them intero= perate" which you agreed to. I have an issue if the framework becomes = a general document for describing a SIP telepresence system architecture. F= or a telepresence system there is functionality beyond CLUE.

      If it simply describes the architecture of how CLUE relates to SIP/SDP/RTP = then I would agree that is in the scope of the framework document. I don= 9;t think it should be a general architecture of all the protocols/interfac= e that a SIP Telepresence system may use.

      With respect to the issue of "saying what we are not doing" then = we may as well remove the text regarding implementation choice.

      --001a11c1f2aa8773e404e8da3194-- From mary.ietf.barnes@gmail.com Wed Oct 16 09:21:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE721F9D30 for ; Wed, 16 Oct 2013 09:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jo-EKd194o-k for ; Wed, 16 Oct 2013 09:21:42 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BBAF521F9D18 for ; Wed, 16 Oct 2013 09:21:35 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ii20so4404525qab.4 for ; Wed, 16 Oct 2013 09:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=8XP+FkCfBhkAI7L/vOVa8n/f/WJzce/E0yqdqRyoLhg=; b=iswysb0KfP1LOKK6McKPuIhSFE2vQmciscP5sdss92Ugl9GfoPjuHWIGmkP7ETTwlm wHAWHEiHl6OAgX+RKBNTcnco0lQ7sOQPBpkl3S/LiMMihA2JmY4+QzzAKMOMkpN7Lfwg WyUNnqcnsgsZSATwvVA2REwNjuplJCuiLlqeTtR8K7CNr+aqyYp88KJKH8EM+e7pSikp mYT3TcvHitrY9aj0de4rYbO7YwjUIvBm1UZFqdO0BzhEUiCBeF7O3ptsa9spPhIgDSVD wa6Pu+tQjmj8pR0OGctlxmEcokywGfEw67rAZatPEGIslHF+nd+eux9p4WJ8VilGSteL EgEg== MIME-Version: 1.0 X-Received: by 10.224.29.69 with SMTP id p5mr6019782qac.30.1381940495073; Wed, 16 Oct 2013 09:21:35 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Wed, 16 Oct 2013 09:21:35 -0700 (PDT) Date: Wed, 16 Oct 2013 11:21:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bf0de3e4f453b04e8de186f Subject: [clue] Minutes: Oct 15, 2013 Design Team meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 16:21:43 -0000 --047d7bf0de3e4f453b04e8de186f Content-Type: text/plain; charset=ISO-8859-1 Hi all, Please note that the minutes (including a link to the recording) from yesterday's design team meeting have been uploaded: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-131015.txt Regards, Mary. --047d7bf0de3e4f453b04e8de186f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      Hi all,

      Please note that the minutes (i= ncluding a link to the recording) from yesterday's design team meeting = have been uploaded:

      Regards,
      Mary.=A0
      --047d7bf0de3e4f453b04e8de186f-- From coverdale@sympatico.ca Wed Oct 16 16:19:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0E811E8189 for ; Wed, 16 Oct 2013 16:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lr8MO+binjE for ; Wed, 16 Oct 2013 16:19:07 -0700 (PDT) Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by ietfa.amsl.com (Postfix) with ESMTP id C847621F9A0C for ; Wed, 16 Oct 2013 16:19:03 -0700 (PDT) Received: from BLU0-SMTP57 ([65.55.116.9]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 16:19:07 -0700 X-TMN: [H4v//yZoanw2Tys8cDKtX7ZENFA46ot3] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.12.62.102]) by BLU0-SMTP57.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 16:19:04 -0700 From: Paul Coverdale To: "'Mary Barnes'" , "'Christian Groves'" References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> In-Reply-To: Date: Wed, 16 Oct 2013 19:18:55 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01CECAA4.8FFEC990" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7KZM1JqRxzGCIlTcaZEoibkmDCRAAYPxCQ Content-Language: en-us X-OriginalArrivalTime: 16 Oct 2013 23:19:04.0568 (UTC) FILETIME=[1B008F80:01CECAC6] Cc: 'CLUE' Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 23:19:12 -0000 ------=_NextPart_000_0087_01CECAA4.8FFEC990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm getting a bit confused after all the multiple in-line comments. What is the proposed text that we are left with? ..Paul From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, October 16, 2013 7:42 AM To: Christian Groves Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt Yet another round of responses below [MB4]. I would like to hear if there's anyone else that shares Christian's concerns. If not, then I will leave the text with the change based on Roberta's input, which seems reasonable to me as the document editor. Thanks, Mary. On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves wrote: Hello Mary, Please see below. Regards, Christian * about dictating architectural choices In the Introduction section, "/It is not the intention of CLUE to dictate telepresence architectural and implementation choices./" I would propose to erase "architectural choice" and to leave only "implementation choice". The CLUE framework should provide some reference architecture for SIP-based telepresence systems in order to let them interoperate, so I would not say that CLUE is not intended to dictate architectural choice. [MB] I agree. [/MB] [CNG] I would prefer to leave the existing text. I believe that was the original intention. [MB] I don't know what you mean by "original intention"? We have a WG deliverable for a framework which does introduce some architectural concepts. Clearly, we aren't prescribing implementation choices. But, we do lay out a model/architecture/framework for the solution. I think we should stick with the text that the majority agrees with. Also, please keep in mind that this is an informational document, thus it's setting the context for the solution, but defines nothing normative per se. [/MB] [CNG] By original intention I mean the original text "It is not the intention of CLUE to dictate telepresence architectural and implementation choices." This is the current text we have "stuck" to. The change isn't just about removing "architectural" from the requirements its also the suggested change to the framework. The current framework document describes a framework for a "protocol" not an overall architectural description of a SIP telepresence system. I think there's enough in the framework rather than adding a discussion on overall SIP telepresence system architecture. That work would be non-trivial. [MB3] Right and removing "architectural" from the sentence is not at all the same thing as saying that CLUE will define an "overall SIP telepresence system architecture". The term "architectural choice" really doesn't mean anything specific, so by saying we are not doing that, it provides no information as to what CLUE isn't doing nor does it result in this document stating that CLUE is making architectural choices. However, some of us would interpret architectural choices to be what protocols one uses and what functional entities use the protocols and how they use those protocols. That is very close to what we are doing with the framework. And, as a matter of fact, that's very much what the term "architecture" means in the context of IETF - e.g., The Internet Architecture Board (IAB): http://www.iab.org/about/iab-overview/ [/MB3] [CNG] I'm not sure what the IAB has to do with CLUE but... I think its an issue of the scope of the "architecture." [MB4] I was referencing the IAB's use of the term "architecture" - follow the link and see the context in which the term is used in the IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG to discuss architectures. [/MB4] As I mentioned above its not so much the deletion of a word its what is intended by that. The following sentence was "the CLUE framework should provide some reference architecture for SIP-based telepresence systems in order to let them interoperate" which you agreed to. I have an issue if the framework becomes a general document for describing a SIP telepresence system architecture. For a telepresence system there is functionality beyond CLUE. [MB4] I think you are reading way too much into the text in this section of the document. It's intended to set the context and has no normative impact on anything that CLUE is doing. It's introductory text. [/MB4] If it simply describes the architecture of how CLUE relates to SIP/SDP/RTP then I would agree that is in the scope of the framework document. I don't think it should be a general architecture of all the protocols/interface that a SIP Telepresence system may use. With respect to the issue of "saying what we are not doing" then we may as well remove the text regarding implementation choice. [MB4] I think the reference to "implementation" choice is important in that it's highlighting the fact that you can make telepresence systems interoperable without having to entirely impact a product design. As you note we are not designing an entire system. [/MB4] ..snip.. _______________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0087_01CECAA4.8FFEC990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      I’m getting a bit confused after all the multiple in-line = comments. What is the proposed text that we are left = with?

       

      ..Paul

       

      From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
      Sent: Wednesday, October 16, 2013 7:42 = AM
      To: Christian Groves
      Cc: CLUE
      Subject: = Re: [clue] comments to = draft-ietf-clue-telepresence-requirements-05.txt

       

      Yet another round of responses below [MB4].   I = would like to hear if there's anyone else that shares Christian's = concerns.  If not, then I will leave the text with the change based = on Roberta's input, which seems reasonable to me as the document = editor.

       

      Thanks,

      Mary. 

       

       

      On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves = <Christian.Groves@nteczone.com> = wrote:

      Hello Mary,

      Please see = below.

      Regards, Christian

       




                  =           * about dictating architectural = choices
                      =         In the Introduction section, "/It is = not the
              intention
            =           of CLUE

            =                   to = dictate telepresence architectural and
              = implementation
                    =           choices./" I would propose to = erase "architectural
                  =     choice" and

                =               to leave only = "implementation choice". The
              = CLUE framework
                    =           should provide some reference = architecture for
              SIP-based
        =                     =   telepresence systems in order to let them
            =           interoperate, so I
          =                     = would not say that CLUE is not intended to dictate
          =                     = architectural choice.

                  =     [MB] I agree. [/MB]


              =     [CNG] I would prefer to leave the existing text. I = believe
              that
            =       was the original intention.

          =     [MB] I don't know what you mean by "original = intention"?            We have a WG = deliverable for a framework which does introduce
            =   some architectural concepts.  Clearly, we aren't = prescribing
              implementation choices. =  But, we do lay out a
              = model/architecture/framework for the solution.  I think = we
              should stick with the text that the = majority agrees with.
              Also, please keep = in mind that this is an informational
              = document, thus it's setting the context for the solution, but
        =       defines nothing normative per se.
          =     [/MB]


          [CNG] By original intention = I mean the original text "It is not
          the intention = of CLUE to dictate telepresence architectural and
          = implementation choices." This is the current text we have = "stuck"
          to. The change isn't just about = removing "architectural" from the
          = requirements its also the suggested change to the framework. = The
          current framework document describes a framework = for a "protocol"
          not an overall architectural = description of a SIP telepresence
          system. I think = there's enough in the framework rather than adding
          a = discussion on overall SIP telepresence system architecture. = That
          work would be non-trivial.

      [MB3] Right and = removing "architectural" from the sentence is not at all the = same thing as saying that CLUE will define an "overall SIP = telepresence system architecture".  The term = "architectural choice" really doesn't mean anything specific, = so by saying we are not doing that, it provides no information as to = what CLUE isn't doing nor does it result in this document stating that = CLUE is making architectural choices.   However, some of us would = interpret architectural choices to be what protocols one uses and what = functional entities use the protocols and how they use those protocols. =  That is very close to what we are doing with the framework. And, = as a matter of fact, that's very much what the term = "architecture" means in the context of IETF - e.g., The = Internet Architecture Board (IAB): http://www.iab.org/about/iab-overview/
      [/MB3]

      [CNG] I'm not = sure what the IAB has to do with CLUE but... I think its an issue of the = scope of the "architecture."

      [MB4] I was referencing the IAB's use of the term = "architecture" - follow the link and see the context in which = the term is used in the IETF.  CLUE is an IETF WG thus it's = entirely appropriate for an IETF WG to discuss architectures. =  [/MB4]

       

       

      As I = mentioned above its not so much the deletion of a word its what is = intended by that. The following sentence was "the CLUE framework = should provide some reference architecture for SIP-based telepresence = systems in order to let them interoperate" which you agreed to. I = have an issue if the framework becomes a general document for describing = a SIP telepresence system architecture. For a telepresence system there = is functionality beyond CLUE.

      [MB4] I think you are reading way too much into the = text in this section of the document.  It's intended to set the = context and has no normative impact on anything that CLUE is doing. =  It's introductory text. = [/MB4] 


      If it = simply describes the architecture of how CLUE relates to SIP/SDP/RTP = then I would agree that is in the scope of the framework document. I = don't think it should be a general architecture of all the = protocols/interface that a SIP Telepresence system may use.

      With = respect to the issue of "saying what we are not doing" then we = may as well remove the text regarding implementation = choice.

      [MB4] I = think the reference to "implementation" choice is important in = that it's highlighting the fact that you can make telepresence systems = interoperable without having to entirely impact a product design. =  As you note we are not designing an entire system. = [/MB4]

       


                  = ..snip..


                  = _______________________________________________
            =       clue mailing list

            =   clue@ietf.org <mailto:clue@ietf.org> = <mailto:clue@ietf.org
              = <mailto:clue@ietf.org>>
            =   https://www.ietf.org/mailman/listinfo/clue

      <= br>

       

       

      ------=_NextPart_000_0087_01CECAA4.8FFEC990-- From Christian.Groves@nteczone.com Wed Oct 16 19:36:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2D321F9D04 for ; Wed, 16 Oct 2013 19:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR3Qvg1UQZl7 for ; Wed, 16 Oct 2013 19:36:03 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDD721F9D12 for ; Wed, 16 Oct 2013 19:36:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAMNLX1J20ReB/2dsb2JhbAANTYM/vlGBNoMZAQEBBAEBAS8BBRsVBgQGARALEQEDAQEBCRYIBwkDAgECARUfAwYIBgEMAQUCAQEFEod3rBaTPI4GgUsHhCUDlCeZG4FT Received: from ppp118-209-23-129.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.23.129]) by ipmail05.adl6.internode.on.net with ESMTP; 17 Oct 2013 13:06:00 +1030 Message-ID: <525F4D0B.8090900@nteczone.com> Date: Thu, 17 Oct 2013 13:35:55 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Paul Coverdale , 'Mary Barnes' References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 'CLUE' Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 02:36:04 -0000 Hello Paul, The original paragraph was: " Telepresence systems of different vendors, today, can follow radically different architectural approaches while offering a similar user experience. It is not the intention of CLUE to dictate telepresence architectural and implementation choices. CLUE enables interoperability between telepresence systems by exchanging information about the systems' characteristics. Systems can use this information to control their behavior to allow for interoperability between those systems." I believe the proposal is to remove "telepresence architectural and" i.e. "It is not the intention of CLUE to dictate implementation choices". The removal of the text was the first part of the proposal the second part was "the CLUE framework should provide some reference architecture for SIP-based telepresence systems in order to let them interoperate". It's this second part that I'm trying to get to the bottom of. Architecture has a wide scope (e.g. as covered by F/H.TPS-Arch). Architecture could relate to simply where CLUE sits with other protocols or it could encompass defining different nodes types, endpoint capabilities, etc. i.e. a telepresence system architecture. The first sentence of the paragraph to me indicates the wider view and there wasn't a proposal to remove this instance. I agree with the current text on the view that CLUE shouldn't describe an overall "telepresence system" architecture. However I do think that CLUE should describe the protocol architecture. So to cover my concern I would propose to expand the sentence: "CLUE will not dictate an overall Telepresence system architecture and implementation choices however it will describe a protocol architecture for CLUE and it relates to other protocols." I think this is consistent with the framework abstract i.e. "This document offers a that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams." Regards, Christian On 17/10/2013 10:18 AM, Paul Coverdale wrote: > > I’m getting a bit confused after all the multiple in-line comments. > What is the proposed text that we are left with? > > ..Paul > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Wednesday, October 16, 2013 7:42 AM > *To:* Christian Groves > *Cc:* CLUE > *Subject:* Re: [clue] comments to > draft-ietf-clue-telepresence-requirements-05.txt > > Yet another round of responses below [MB4]. I would like to hear if > there's anyone else that shares Christian's concerns. If not, then I > will leave the text with the change based on Roberta's input, which > seems reasonable to me as the document editor. > > Thanks, > > Mary. > > On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves > > > wrote: > > Hello Mary, > > Please see below. > > Regards, Christian > > > > > * about dictating architectural choices > In the Introduction section, "/It is not the > intention > of CLUE > > to dictate telepresence architectural and > implementation > choices./" I would propose to erase "architectural > choice" and > > to leave only "implementation choice". The > CLUE framework > should provide some reference architecture for > SIP-based > telepresence systems in order to let them > interoperate, so I > would not say that CLUE is not intended to dictate > architectural choice. > > [MB] I agree. [/MB] > > > [CNG] I would prefer to leave the existing text. I believe > that > was the original intention. > > [MB] I don't know what you mean by "original intention"? We have a > WG deliverable for a framework which does introduce > some architectural concepts. Clearly, we aren't prescribing > implementation choices. But, we do lay out a > model/architecture/framework for the solution. I think we > should stick with the text that the majority agrees with. > Also, please keep in mind that this is an informational > document, thus it's setting the context for the solution, but > defines nothing normative per se. > [/MB] > > > [CNG] By original intention I mean the original text "It is not > the intention of CLUE to dictate telepresence architectural and > implementation choices." This is the current text we have "stuck" > to. The change isn't just about removing "architectural" from the > requirements its also the suggested change to the framework. The > current framework document describes a framework for a "protocol" > not an overall architectural description of a SIP telepresence > system. I think there's enough in the framework rather than adding > a discussion on overall SIP telepresence system architecture. That > work would be non-trivial. > > [MB3] Right and removing "architectural" from the sentence is not > at all the same thing as saying that CLUE will define an "overall > SIP telepresence system architecture". The term "architectural > choice" really doesn't mean anything specific, so by saying we are > not doing that, it provides no information as to what CLUE isn't > doing nor does it result in this document stating that CLUE is > making architectural choices. However, some of us would interpret > architectural choices to be what protocols one uses and what > functional entities use the protocols and how they use those > protocols. That is very close to what we are doing with the > framework. And, as a matter of fact, that's very much what the > term "architecture" means in the context of IETF - e.g., The > Internet Architecture Board (IAB): > http://www.iab.org/about/iab-overview/ > [/MB3] > > [CNG] I'm not sure what the IAB has to do with CLUE but... I think its > an issue of the scope of the "architecture." > > [MB4] I was referencing the IAB's use of the term "architecture" - > follow the link and see the context in which the term is used in the > IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG > to discuss architectures. [/MB4] > > As I mentioned above its not so much the deletion of a word its > what is intended by that. The following sentence was "the CLUE > framework should provide some reference architecture for SIP-based > telepresence systems in order to let them interoperate" which you > agreed to. I have an issue if the framework becomes a general > document for describing a SIP telepresence system architecture. > For a telepresence system there is functionality beyond CLUE. > > [MB4] I think you are reading way too much into the text in this > section of the document. It's intended to set the context and has no > normative impact on anything that CLUE is doing. It's introductory > text. [/MB4] > > > If it simply describes the architecture of how CLUE relates to > SIP/SDP/RTP then I would agree that is in the scope of the > framework document. I don't think it should be a general > architecture of all the protocols/interface that a SIP > Telepresence system may use. > > With respect to the issue of "saying what we are not doing" then > we may as well remove the text regarding implementation choice. > > [MB4] I think the reference to "implementation" choice is important in > that it's highlighting the fact that you can make telepresence systems > interoperable without having to entirely impact a product design. As > you note we are not designing an entire system. [/MB4] > > > ..snip.. > > > _______________________________________________ > clue mailing list > > clue@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/clue > > > From mary.ietf.barnes@gmail.com Thu Oct 17 05:59:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBA921F91F2 for ; Thu, 17 Oct 2013 05:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.56 X-Spam-Level: X-Spam-Status: No, score=-101.56 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9B3Y1OV6ehi for ; Thu, 17 Oct 2013 05:59:12 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C2B6D11E81CC for ; Thu, 17 Oct 2013 05:58:21 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so521936qea.18 for ; Thu, 17 Oct 2013 05:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QQw8oKBJ0DBMnELyg97sr5F3fI+CBMOl3wzU9IGYSN8=; b=eNm8GRSvxIWJRBT7BHIFr7BfcEhLLINiyZ76jjDSVM36wV2WAgetQNwczRpTzbqfFR Y2T0EjtGoAkbw1fJS1Wf1FRjj98VjtzC1dtulJuwTAeLJz0ATBIjK3UI9aSoJenAs1Ii e/uXnPhX7+e/dIagcBR4dJpkfkOAJfnzKWQ9sVreWr1YcucbRpEIOs/w5dO0495dWiFP 1PO2+u6A3pkTQTsx3nWmuqhs8g+i9oznXrSZC8wdo57AMxCHb0y2JoRxPM7IYMOvEzqu s64EHSYOSPQdhXUxoyG4Qm2VrbuZWaFGS9t2Xcpuznpe2iBLY7XkL9ZehG2c+fBtiQbA OaVQ== MIME-Version: 1.0 X-Received: by 10.49.72.201 with SMTP id f9mr3652117qev.49.1382014701016; Thu, 17 Oct 2013 05:58:21 -0700 (PDT) Received: by 10.49.117.234 with HTTP; Thu, 17 Oct 2013 05:58:20 -0700 (PDT) In-Reply-To: <525F4D0B.8090900@nteczone.com> References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> <525F4D0B.8090900@nteczone.com> Date: Thu, 17 Oct 2013 07:58:20 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7b677be4541c7604e8ef5f14 Cc: CLUE Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:59:15 -0000 --047d7b677be4541c7604e8ef5f14 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 16, 2013 at 9:35 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Paul, > > The original paragraph was: > " Telepresence systems of different vendors, today, can follow > radically different architectural approaches while offering a similar > user experience. It is not the intention of CLUE to dictate > telepresence architectural and implementation choices. CLUE enables > interoperability between telepresence systems by exchanging > information about the systems' characteristics. Systems can use this > information to control their behavior to allow for interoperability > between those systems." > > I believe the proposal is to remove "telepresence architectural and" i.e. > "It is not the intention of CLUE to dictate implementation choices". > > The removal of the text was the first part of the proposal the second par= t > was "the CLUE framework should provide some reference architecture for > SIP-based telepresence systems in order to let them interoperate". > > It's this second part that I'm trying to get to the bottom of. > Architecture has a wide scope (e.g. as covered by F/H.TPS-Arch). > Architecture could relate to simply where CLUE sits with other protocols = or > it could encompass defining different nodes types, endpoint capabilities, > etc. i.e. a telepresence system architecture. The first sentence of the > paragraph to me indicates the wider view and there wasn't a proposal to > remove this instance. I agree with the current text on the view that CLUE > shouldn't describe an overall "telepresence system" architecture. However= I > do think that CLUE should describe the protocol architecture. [MB] There was never any intention of adding text for the second. Roberta's sentence is just explaining why she thinks we should remove the "architectural" choices from that 1st sentence. [/MB] > > So to cover my concern I would propose to expand the sentence: > "CLUE will not dictate an overall Telepresence system architecture and > implementation choices however it will describe a protocol architecture f= or > CLUE and it relates to other protocols." > [MB] It would have been nice if you had provided your proposed sentence way earlier in this thread because I had no understanding that you were proposing that (since Roberta was only proposing to remove the word and NOT add any new text). I understood you were just debating removing the "architectural" choice. As I have already said, removing the term "architectural" makes NO implication as to what CLUE is or is not doing in terms of protocols, etc. But, if others are okay with the newly proposed change, that's fine. [/MB] > > I think this is consistent with the framework abstract i.e. "This documen= t > offers a that enables devices in a telepresenc= e > conference to interoperate by specifying the relationships between multip= le > media streams." > [MB] Right - that's in the framework so I'm not sure we need that level of detail in the *Introduction* to the requirements document. But, I have already spent way too much time on this circular debate, so as long as others agree, we can make that change. [/MB] > > Regards, Christian > > > On 17/10/2013 10:18 AM, Paul Coverdale wrote: > >> >> I=92m getting a bit confused after all the multiple in-line comments. Wh= at >> is the proposed text that we are left with? >> >> ..Paul >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* Wednesday, October 16, 2013 7:42 AM >> *To:* Christian Groves >> *Cc:* CLUE >> *Subject:* Re: [clue] comments to draft-ietf-clue-telepresence-** >> requirements-05.txt >> >> >> Yet another round of responses below [MB4]. I would like to hear if >> there's anyone else that shares Christian's concerns. If not, then I wil= l >> leave the text with the change based on Roberta's input, which seems >> reasonable to me as the document editor. >> >> Thanks, >> >> Mary. >> >> On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello Mary, >> >> Please see below. >> >> Regards, Christian >> >> >> >> >> * about dictating architectural choices >> In the Introduction section, "/It is not the >> intention >> of CLUE >> >> to dictate telepresence architectural and >> implementation >> choices./" I would propose to erase "architectural >> choice" and >> >> to leave only "implementation choice". The >> CLUE framework >> should provide some reference architecture for >> SIP-based >> telepresence systems in order to let them >> interoperate, so I >> would not say that CLUE is not intended to dictate >> architectural choice. >> >> [MB] I agree. [/MB] >> >> >> [CNG] I would prefer to leave the existing text. I believe >> that >> was the original intention. >> >> [MB] I don't know what you mean by "original intention"? We have a >> WG deliverable for a framework which does introduce >> some architectural concepts. Clearly, we aren't prescribing >> implementation choices. But, we do lay out a >> model/architecture/framework for the solution. I think we >> should stick with the text that the majority agrees with. >> Also, please keep in mind that this is an informational >> document, thus it's setting the context for the solution, but >> defines nothing normative per se. >> [/MB] >> >> >> [CNG] By original intention I mean the original text "It is not >> the intention of CLUE to dictate telepresence architectural and >> implementation choices." This is the current text we have "stuck" >> to. The change isn't just about removing "architectural" from the >> requirements its also the suggested change to the framework. The >> current framework document describes a framework for a "protocol" >> not an overall architectural description of a SIP telepresence >> system. I think there's enough in the framework rather than adding >> a discussion on overall SIP telepresence system architecture. That >> work would be non-trivial. >> >> [MB3] Right and removing "architectural" from the sentence is not >> at all the same thing as saying that CLUE will define an "overall >> SIP telepresence system architecture". The term "architectural >> choice" really doesn't mean anything specific, so by saying we are >> not doing that, it provides no information as to what CLUE isn't >> doing nor does it result in this document stating that CLUE is >> making architectural choices. However, some of us would interpret >> architectural choices to be what protocols one uses and what >> functional entities use the protocols and how they use those >> protocols. That is very close to what we are doing with the >> framework. And, as a matter of fact, that's very much what the >> term "architecture" means in the context of IETF - e.g., The >> Internet Architecture Board (IAB): >> http://www.iab.org/about/iab-**overview/ >> [/MB3] >> >> [CNG] I'm not sure what the IAB has to do with CLUE but... I think its a= n >> issue of the scope of the "architecture." >> >> [MB4] I was referencing the IAB's use of the term "architecture" - follo= w >> the link and see the context in which the term is used in the IETF. CLUE= is >> an IETF WG thus it's entirely appropriate for an IETF WG to discuss >> architectures. [/MB4] >> >> As I mentioned above its not so much the deletion of a word its >> what is intended by that. The following sentence was "the CLUE >> framework should provide some reference architecture for SIP-based >> telepresence systems in order to let them interoperate" which you >> agreed to. I have an issue if the framework becomes a general >> document for describing a SIP telepresence system architecture. >> For a telepresence system there is functionality beyond CLUE. >> >> [MB4] I think you are reading way too much into the text in this section >> of the document. It's intended to set the context and has no normative >> impact on anything that CLUE is doing. It's introductory text. [/MB4] >> >> >> If it simply describes the architecture of how CLUE relates to >> SIP/SDP/RTP then I would agree that is in the scope of the >> framework document. I don't think it should be a general >> architecture of all the protocols/interface that a SIP >> Telepresence system may use. >> >> With respect to the issue of "saying what we are not doing" then >> we may as well remove the text regarding implementation choice. >> >> [MB4] I think the reference to "implementation" choice is important in >> that it's highlighting the fact that you can make telepresence systems >> interoperable without having to entirely impact a product design. As you >> note we are not designing an entire system. [/MB4] >> >> >> ..snip.. >> >> >> ______________________________**_________________ >> clue mailing list >> >> clue@ietf.org > > > >> >> >> https://www.ietf.org/mailman/**listinfo/clue >> >> >> >> > --047d7b677be4541c7604e8ef5f14 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



      On Wed, Oct 16, 2013 at 9:35 PM, Christian Groves <Chr= istian.Groves@nteczone.com> wrote:
      Hello Paul,

      The original paragraph was:
      " Telepresence systems of different vendors, today, can follow
      radically different architectural approaches while offering a similar
      user experience. It is not the intention of CLUE to dictate
      telepresence architectural and implementation choices. CLUE enables
      interoperability between telepresence systems by exchanging
      information about the systems' characteristics. Systems can use this information to control their behavior to allow for interoperability
      between those systems."

      I believe the proposal is to remove "telepresence architectural and&qu= ot; i.e. "It is not the intention of CLUE to dictate implementation ch= oices".

      The removal of the text was the first part of the proposal the second part = was "the CLUE framework should provide some reference architecture for= SIP-based telepresence systems in order to let them interoperate".
      It's this second part that I'm trying to get to the bottom of. Arch= itecture has a wide scope (e.g. as covered by F/H.TPS-Arch). Architecture c= ould relate to simply where CLUE sits with other protocols or it could enco= mpass defining different nodes types, endpoint capabilities, etc. i.e. a te= lepresence system architecture. The first sentence of the paragraph to me i= ndicates the wider view and there wasn't a proposal to remove this inst= ance. I agree with the current text on the view that CLUE shouldn't des= cribe an overall "telepresence system" architecture. However I do= think that CLUE should describe the protocol architecture.=A0
      [MB] There was never any intention of adding text for the second= . Roberta's sentence is just explaining why she thinks we should remove= the "architectural" choices from that 1st sentence. [/MB]=A0

      So to cover my concern I would propose to expand the sentence:
      "CLUE will not dictate an overall Telepresence system architecture and= implementation choices however it will describe a protocol architecture fo= r CLUE and it relates to other protocols."
      [MB] =A0It would have been nice if you had provided your proposed sentence = way earlier in this thread because I had no understanding that you were pro= posing that (since Roberta was only proposing to remove the word and NOT ad= d any new text). =A0I understood you were just debating removing the "= architectural" choice. =A0As I have already said, removing the term &q= uot;architectural" makes NO implication as to what CLUE is or is not d= oing in terms of protocols, etc. =A0But, if others are okay with the newly = proposed change, that's fine.=A0
      [/MB]

      I think this is consistent with the framework abstract i.e. "This docu= ment offers a <framework for a protocol> that enables devices in a te= lepresence conference to interoperate by specifying the relationships betwe= en multiple media streams."
      [MB] Right - that's in the framework so I'm= not sure we need that level of detail in the *Introduction* to the require= ments document. But, I have already spent way too much time on this circula= r debate, so as long as others agree, we can make that change. =A0[/MB]=A0<= /div>

      Regards, Christian


      On 17/10/2013 10:18 AM, Paul Coverdale wrote:

      I=92m getting a bit confused after all the multiple in-line comments. What = is the proposed text that we are left with?

      ..Paul

      *From:*clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes
      *Sent:* Wednesday, October 16, 2013 7:42 AM
      *To:* Christian Groves
      *Cc:* CLUE
      *Subject:* Re: [clue] comments to draft-ietf-clue-telepresence-requi= rements-05.txt


      Yet another round of responses below [MB4]. I would like to hear if there&#= 39;s anyone else that shares Christian's concerns. If not, then I will = leave the text with the change based on Roberta's input, which seems re= asonable to me as the document editor.

      Thanks,

      Mary.

      On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

      Hello Mary,

      Please see below.

      Regards, Christian




      =A0 =A0 * about dictating architectural choices
      =A0 =A0 In the Introduction section, "/It is not the
      =A0 =A0 intention
      =A0 =A0 of CLUE

      =A0 =A0 to dictate telepresence architectural and
      =A0 =A0 implementation
      =A0 =A0 choices./" I would propose to erase "architectural
      =A0 =A0 choice" and

      =A0 =A0 to leave only "implementation choice". The
      =A0 =A0 CLUE framework
      =A0 =A0 should provide some reference architecture for
      =A0 =A0 SIP-based
      =A0 =A0 telepresence systems in order to let them
      =A0 =A0 interoperate, so I
      =A0 =A0 would not say that CLUE is not intended to dictate
      =A0 =A0 architectural choice.

      =A0 =A0 [MB] I agree. [/MB]


      =A0 =A0 [CNG] I would prefer to leave the existing text. I believe
      =A0 =A0 that
      =A0 =A0 was the original intention.

      =A0 =A0 [MB] I don't know what you mean by "original intention&quo= t;? We have a
      =A0 =A0 WG deliverable for a framework which does introduce
      =A0 =A0 some architectural concepts. Clearly, we aren't prescribing
      =A0 =A0 implementation choices. But, we do lay out a
      =A0 =A0 model/architecture/framework for the solution. I think we
      =A0 =A0 should stick with the text that the majority agrees with.
      =A0 =A0 Also, please keep in mind that this is an informational
      =A0 =A0 document, thus it's setting the context for the solution, but =A0 =A0 defines nothing normative per se.
      =A0 =A0 [/MB]


      =A0 =A0 [CNG] By original intention I mean the original text "It is no= t
      =A0 =A0 the intention of CLUE to dictate telepresence architectural and
      =A0 =A0 implementation choices." This is the current text we have &quo= t;stuck"
      =A0 =A0 to. The change isn't just about removing "architectural&qu= ot; from the
      =A0 =A0 requirements its also the suggested change to the framework. The =A0 =A0 current framework document describes a framework for a "protoc= ol"
      =A0 =A0 not an overall architectural description of a SIP telepresence
      =A0 =A0 system. I think there's enough in the framework rather than add= ing
      =A0 =A0 a discussion on overall SIP telepresence system architecture. That<= br> =A0 =A0 work would be non-trivial.

      =A0 =A0 [MB3] Right and removing "architectural" from the sentenc= e is not
      =A0 =A0 at all the same thing as saying that CLUE will define an "over= all
      =A0 =A0 SIP telepresence system architecture". The term "architec= tural
      =A0 =A0 choice" really doesn't mean anything specific, so by sayin= g we are
      =A0 =A0 not doing that, it provides no information as to what CLUE isn'= t
      =A0 =A0 doing nor does it result in this document stating that CLUE is
      =A0 =A0 making architectural choices. However, some of us would interpret =A0 =A0 architectural choices to be what protocols one uses and what
      =A0 =A0 functional entities use the protocols and how they use those
      =A0 =A0 protocols. That is very close to what we are doing with the
      =A0 =A0 framework. And, as a matter of fact, that's very much what the<= br> =A0 =A0 term "architecture" means in the context of IETF - e.g., = The
      =A0 =A0 Internet Architecture Board (IAB):
      =A0 =A0 http://www.iab.org/about/iab-overview/
      =A0 =A0 [/MB3]

      [CNG] I'm not sure what the IAB has to do with CLUE but... I think its = an issue of the scope of the "architecture."

      [MB4] I was referencing the IAB's use of the term "architecture&qu= ot; - follow the link and see the context in which the term is used in the = IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG = to discuss architectures. [/MB4]

      =A0 =A0 As I mentioned above its not so much the deletion of a word its
      =A0 =A0 what is intended by that. The following sentence was "the CLUE=
      =A0 =A0 framework should provide some reference architecture for SIP-based<= br> =A0 =A0 telepresence systems in order to let them interoperate" which = you
      =A0 =A0 agreed to. I have an issue if the framework becomes a general
      =A0 =A0 document for describing a SIP telepresence system architecture.
      =A0 =A0 For a telepresence system there is functionality beyond CLUE.

      [MB4] I think you are reading way too much into the text in this section of= the document. It's intended to set the context and has no normative im= pact on anything that CLUE is doing. It's introductory text. [/MB4]


      =A0 =A0 If it simply describes the architecture of how CLUE relates to
      =A0 =A0 SIP/SDP/RTP then I would agree that is in the scope of the
      =A0 =A0 framework document. I don't think it should be a general
      =A0 =A0 architecture of all the protocols/interface that a SIP
      =A0 =A0 Telepresence system may use.

      =A0 =A0 With respect to the issue of "saying what we are not doing&quo= t; then
      =A0 =A0 we may as well remove the text regarding implementation choice.

      [MB4] I think the reference to "implementation" choice is importa= nt in that it's highlighting the fact that you can make telepresence sy= stems interoperable without having to entirely impact a product design. As = you note we are not designing an entire system. [/MB4]


      =A0 =A0 =A0 =A0 ..snip..


      =A0 =A0 =A0 =A0 _______________________________________________
      =A0 =A0 =A0 =A0 clue mailing list

      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org <mailto:clue@ietf.org>>>
      =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue





      --047d7b677be4541c7604e8ef5f14-- From coverdale@sympatico.ca Thu Oct 17 08:42:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C13111E8266 for ; Thu, 17 Oct 2013 08:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdaKYZNxzKGZ for ; Thu, 17 Oct 2013 08:42:50 -0700 (PDT) Received: from blu0-omc1-s36.blu0.hotmail.com (blu0-omc1-s36.blu0.hotmail.com [65.55.116.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5B29A11E8242 for ; Thu, 17 Oct 2013 08:42:50 -0700 (PDT) Received: from BLU0-SMTP74 ([65.55.116.7]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Oct 2013 08:42:55 -0700 X-TMN: [wV71hiou8vESn+VIBQCtooMV8SXhS7co] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([70.26.38.87]) by BLU0-SMTP74.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Oct 2013 08:42:52 -0700 From: Paul Coverdale To: "'Christian Groves'" , "'Mary Barnes'" References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> <525F4D0B.8090900@nteczone.com> In-Reply-To: <525F4D0B.8090900@nteczone.com> Date: Thu, 17 Oct 2013 11:42:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7K4aZ9QvV+ekwhSwqR3gpC95vS1gAbO8ew Content-Language: en-us X-OriginalArrivalTime: 17 Oct 2013 15:42:52.0432 (UTC) FILETIME=[8A59D100:01CECB4F] Cc: 'CLUE' Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:42:55 -0000 OK, thanks for the clarification, Christian. I agree with your concern and I support your new proposed text, with a slight change to correct the English (addition of a semi-colon and the word "how"). So the new text reads: "CLUE will not dictate an overall Telepresence system architecture and implementation choices; however it will describe a protocol architecture for CLUE and how it relates to other protocols." ...Paul >-----Original Message----- >From: Christian Groves [mailto:Christian.Groves@nteczone.com] >Sent: Wednesday, October 16, 2013 10:36 PM >To: Paul Coverdale; 'Mary Barnes' >Cc: 'CLUE' >Subject: Re: [clue] comments to draft-ietf-clue-telepresence- >requirements-05.txt > >Hello Paul, > >The original paragraph was: >" Telepresence systems of different vendors, today, can follow radically >different architectural approaches while offering a similar user >experience. It is not the intention of CLUE to dictate telepresence >architectural and implementation choices. CLUE enables interoperability >between telepresence systems by exchanging information about the >systems' characteristics. Systems can use this information to control >their behavior to allow for interoperability between those systems." > >I believe the proposal is to remove "telepresence architectural and" >i.e. "It is not the intention of CLUE to dictate implementation >choices". > >The removal of the text was the first part of the proposal the second >part was "the CLUE framework should provide some reference architecture >for SIP-based telepresence systems in order to let them interoperate". > >It's this second part that I'm trying to get to the bottom of. >Architecture has a wide scope (e.g. as covered by F/H.TPS-Arch). >Architecture could relate to simply where CLUE sits with other protocols >or it could encompass defining different nodes types, endpoint >capabilities, etc. i.e. a telepresence system architecture. The first >sentence of the paragraph to me indicates the wider view and there >wasn't a proposal to remove this instance. I agree with the current text >on the view that CLUE shouldn't describe an overall "telepresence >system" architecture. However I do think that CLUE should describe the >protocol architecture. > >So to cover my concern I would propose to expand the sentence: >"CLUE will not dictate an overall Telepresence system architecture and >implementation choices however it will describe a protocol architecture >for CLUE and it relates to other protocols." > >I think this is consistent with the framework abstract i.e. "This >document offers a that enables devices in a >telepresence conference to interoperate by specifying the relationships >between multiple media streams." > >Regards, Christian > >On 17/10/2013 10:18 AM, Paul Coverdale wrote: >> >> I'm getting a bit confused after all the multiple in-line comments. >> What is the proposed text that we are left with? >> >> ..Paul >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* Wednesday, October 16, 2013 7:42 AM >> *To:* Christian Groves >> *Cc:* CLUE >> *Subject:* Re: [clue] comments to >> draft-ietf-clue-telepresence-requirements-05.txt >> >> Yet another round of responses below [MB4]. I would like to hear if >> there's anyone else that shares Christian's concerns. If not, then I >> will leave the text with the change based on Roberta's input, which >> seems reasonable to me as the document editor. >> >> Thanks, >> >> Mary. >> >> On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves >> > >> wrote: >> >> Hello Mary, >> >> Please see below. >> >> Regards, Christian >> >> >> >> >> * about dictating architectural choices >> In the Introduction section, "/It is not the >> intention >> of CLUE >> >> to dictate telepresence architectural and >> implementation >> choices./" I would propose to erase "architectural >> choice" and >> >> to leave only "implementation choice". The >> CLUE framework >> should provide some reference architecture for >> SIP-based >> telepresence systems in order to let them >> interoperate, so I >> would not say that CLUE is not intended to dictate >> architectural choice. >> >> [MB] I agree. [/MB] >> >> >> [CNG] I would prefer to leave the existing text. I believe >> that >> was the original intention. >> >> [MB] I don't know what you mean by "original intention"? We have a >> WG deliverable for a framework which does introduce >> some architectural concepts. Clearly, we aren't prescribing >> implementation choices. But, we do lay out a >> model/architecture/framework for the solution. I think we >> should stick with the text that the majority agrees with. >> Also, please keep in mind that this is an informational >> document, thus it's setting the context for the solution, but >> defines nothing normative per se. >> [/MB] >> >> >> [CNG] By original intention I mean the original text "It is not >> the intention of CLUE to dictate telepresence architectural and >> implementation choices." This is the current text we have "stuck" >> to. The change isn't just about removing "architectural" from the >> requirements its also the suggested change to the framework. The >> current framework document describes a framework for a "protocol" >> not an overall architectural description of a SIP telepresence >> system. I think there's enough in the framework rather than adding >> a discussion on overall SIP telepresence system architecture. That >> work would be non-trivial. >> >> [MB3] Right and removing "architectural" from the sentence is not >> at all the same thing as saying that CLUE will define an "overall >> SIP telepresence system architecture". The term "architectural >> choice" really doesn't mean anything specific, so by saying we are >> not doing that, it provides no information as to what CLUE isn't >> doing nor does it result in this document stating that CLUE is >> making architectural choices. However, some of us would interpret >> architectural choices to be what protocols one uses and what >> functional entities use the protocols and how they use those >> protocols. That is very close to what we are doing with the >> framework. And, as a matter of fact, that's very much what the >> term "architecture" means in the context of IETF - e.g., The >> Internet Architecture Board (IAB): >> http://www.iab.org/about/iab-overview/ >> [/MB3] >> >> [CNG] I'm not sure what the IAB has to do with CLUE but... I think its >> an issue of the scope of the "architecture." >> >> [MB4] I was referencing the IAB's use of the term "architecture" - >> follow the link and see the context in which the term is used in the >> IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG >> to discuss architectures. [/MB4] >> >> As I mentioned above its not so much the deletion of a word its >> what is intended by that. The following sentence was "the CLUE >> framework should provide some reference architecture for SIP-based >> telepresence systems in order to let them interoperate" which you >> agreed to. I have an issue if the framework becomes a general >> document for describing a SIP telepresence system architecture. >> For a telepresence system there is functionality beyond CLUE. >> >> [MB4] I think you are reading way too much into the text in this >> section of the document. It's intended to set the context and has no >> normative impact on anything that CLUE is doing. It's introductory >> text. [/MB4] >> >> >> If it simply describes the architecture of how CLUE relates to >> SIP/SDP/RTP then I would agree that is in the scope of the >> framework document. I don't think it should be a general >> architecture of all the protocols/interface that a SIP >> Telepresence system may use. >> >> With respect to the issue of "saying what we are not doing" then >> we may as well remove the text regarding implementation choice. >> >> [MB4] I think the reference to "implementation" choice is important in >> that it's highlighting the fact that you can make telepresence systems >> interoperable without having to entirely impact a product design. As >> you note we are not designing an entire system. [/MB4] >> >> >> ..snip.. >> >> >> _______________________________________________ >> clue mailing list >> >> clue@ietf.org > > > >> >> >> https://www.ietf.org/mailman/listinfo/clue >> >> >> From internet-drafts@ietf.org Sat Oct 19 07:54:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1E21F9E88; Sat, 19 Oct 2013 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCfu-6CHUcJW; Sat, 19 Oct 2013 07:54:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FBB11E81BF; Sat, 19 Oct 2013 07:54:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019145451.9591.10102.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 07:54:51 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 14:54:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-12.txt Pages : 51 Date : 2013-10-19 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-12 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 internet-drafts@ietf.org Mon Oct 21 09:14:50 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB311E8643; Mon, 21 Oct 2013 09:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ndJX3lNvQar; Mon, 21 Oct 2013 09:14:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCC611E83F7; Mon, 21 Oct 2013 09:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021161446.12963.21177.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 09:14:46 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:14:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Mapping RTP streams to CLUE media captures Author(s) : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-01.txt Pages : 17 Date : 2013-10-21 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-rtp-mapping-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 internet-drafts@ietf.org Mon Oct 21 10:47:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FF511E8385; Mon, 21 Oct 2013 10:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mUzfoyZFgdG; Mon, 21 Oct 2013 10:47:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7C11E818F; Mon, 21 Oct 2013 10:46:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021174556.32455.31080.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 10:45:56 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 17:47:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-requirements-06.txt Pages : 14 Date : 2013-10-21 Abstract: This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and related definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirement= s-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Christian.Groves@nteczone.com Mon Oct 21 23:21:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAC511E8481 for ; Mon, 21 Oct 2013 23:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9+w5YVcpQJg for ; Mon, 21 Oct 2013 23:21:27 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 99B3E11E847E for ; Mon, 21 Oct 2013 23:21:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJ0YZlJ20XZR/2dsb2JhbAANTIM/vwsJgTeDGQEBAQQBAQE1GxUGCg0ECxEEAQEBCQMTCAcJAwIBAgEVHwkIEwYCAQGID6dOk0IEjhKBUAaEIwOUKpkegVQFBA Received: from ppp118-209-118-81.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.118.81]) by ipmail06.adl2.internode.on.net with ESMTP; 22 Oct 2013 16:51:16 +1030 Message-ID: <52661954.2010202@nteczone.com> Date: Tue, 22 Oct 2013 17:21:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:21:27 -0000 Hello Mark, I guess I saw this slightly differently. Rather than chose the MC based on voice activity I saw that a consumer would chose the MC in the MCC based on the sources it wanted. It would then choose an applicable policy (i.e. most active, two most active, etc). The MCU would provide the appropriate MC based on this policy. For the "most recent talker list" it sounds like a subscribe/notify mechanism where the Consumer would subscribe to events and then be notified of it. Is this the sort of thing that you were thinking of? Regards, Christian On 12/10/2013 2:57 AM, Duckworth, Mark wrote: > I'm branching this topic off the MCC discussion, keeping just a small section of previous email. > > I have another suggestion to consider about making media switching decisions - see below. Has anybody else considered an idea like this? > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Robert Hansen >> Sent: Monday, September 30, 2013 12:43 PM >> To: clue@ietf.org >> Subject: Re: [clue] Example of MCC >> >>> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: >>>> One downside to this approach is that every change the MCU makes in >>>> how it assigns contributing VCs to an MCC (e.g. make a switch based >>>> on current talker) could result in the consumer renderer needing to >>>> change how it maps decoder output to display locations. I need to >>>> think more about if this would really be a problem or not. >> [RH] My issue with using the spatial coordinates of the MCC is that it requires >> the MCU to anticipate the rendering desires of the endpoint, as the MCU will >> need to advertise MCCs with spatial coordinates that allow the endpoint to >> do what it wants to do. My concern has always been that this may lead to >> huge numbers of MCCs and capture scene entries if the MCU is trying to >> anticipate potential layouts by the endpoint. > I agree it is good if the MCU does not have to anticipate the rendering (layout) desires of the endpoint consumer. So I consider if it is better if the consumer can make even more of the decisions, including dynamically selecting which source capture should be included in an MCC. draft-groves-clue-multi-content-00 says "The Consumer may or may not want to receive all the indicated captures. Therefore it can choose to receive a sub-set of captures indicated by the MCC." This means the consumer can choose, in a configure message, to receive the one particular capture it wants at that moment, for each MCC. And it can send new configure messages any time, to change this choice. I think this would not require any SDP exchanges. > > If the consumer makes these choices (which still must be consistent with the advertisement), then the provider doesn't have to make any switching choices any more. The consumer can make its choices based on its own local policy for layout and rendering. > > But the consumer would need some more information about current activity in the conference in order to make these decisions. The consumer would need to know about audio activity, for example in the form of a "most recent talker list" or something like that, in order to make the decisions about which MC it wants to receive within each MCC. I don't know of any existing standard way to convey that information. It seems to me a provider could send a "most recent talker list" to a consumer via the CLUE channel. Is anybody interested in pursuing this idea? > > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Tue Oct 22 03:14:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609BD11E8192 for ; Tue, 22 Oct 2013 03:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGs-EEyMhA+K for ; Tue, 22 Oct 2013 03:14:04 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id CA01511E8256 for ; Tue, 22 Oct 2013 03:14:00 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 22 Oct 2013 03:14:00 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 22 Oct 2013 03:13:57 -0700 Thread-Topic: [clue] Example of MCC - consumer driven layout and switching Thread-Index: Ac7O7vMMwVg2eFecSl6zP1IG2dNtDQAHqrfA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D603A7C3B9@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> <52661954.2010202@nteczone.com> In-Reply-To: <52661954.2010202@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:14:08 -0000 Hi Christian, I understand the scenario you are talking about, where the MCU chooses the = MC for the MCC based on some policy. But I think it leads to some potential= problems. Like we said below, the MCU has to anticipate the rendering des= ires of the receiving endpoint, at least to some extent. And also the rece= iving endpoint might have to remap a video decoder to a different rendering= location every time the MCU makes a switch. This seems like a problem for= an endpoint that has particular decoders hardwired to different displays. = I think these problems can be resolved if the receiver makes more explicit= choices about what it wants to receive in each MCC. Yes, I was thinking of something like a subscribe/notify mechanism for a "r= ecent talker list". I'm not sure it's really needed though, maybe instead = the receiver can get this information from the audio streams, if the MCU se= nds something like the N most active audio streams. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Tuesday, October 22, 2013 2:21 AM > To: clue@ietf.org > Subject: Re: [clue] Example of MCC - consumer driven layout and switching >=20 > Hello Mark, >=20 > I guess I saw this slightly differently. Rather than chose the MC based o= n > voice activity I saw that a consumer would chose the MC in the MCC based > on the sources it wanted. It would then choose an applicable policy (i.e.= most > active, two most active, etc). The MCU would provide the appropriate MC > based on this policy. >=20 > For the "most recent talker list" it sounds like a subscribe/notify mecha= nism > where the Consumer would subscribe to events and then be notified of it. = Is > this the sort of thing that you were thinking of? >=20 > Regards, Christian >=20 > On 12/10/2013 2:57 AM, Duckworth, Mark wrote: > > I'm branching this topic off the MCC discussion, keeping just a small s= ection > of previous email. > > > > I have another suggestion to consider about making media switching > decisions - see below. Has anybody else considered an idea like this? > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Robert Hansen > >> Sent: Monday, September 30, 2013 12:43 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Example of MCC > >> > >>> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: > >>>> One downside to this approach is that every change the MCU makes in > >>>> how it assigns contributing VCs to an MCC (e.g. make a switch based > >>>> on current talker) could result in the consumer renderer needing to > >>>> change how it maps decoder output to display locations. I need to > >>>> think more about if this would really be a problem or not. > >> [RH] My issue with using the spatial coordinates of the MCC is that > >> it requires the MCU to anticipate the rendering desires of the > >> endpoint, as the MCU will need to advertise MCCs with spatial > >> coordinates that allow the endpoint to do what it wants to do. My > >> concern has always been that this may lead to huge numbers of MCCs > >> and capture scene entries if the MCU is trying to anticipate potential > layouts by the endpoint. > > I agree it is good if the MCU does not have to anticipate the rendering > (layout) desires of the endpoint consumer. So I consider if it is better= if the > consumer can make even more of the decisions, including dynamically > selecting which source capture should be included in an MCC. draft-grove= s- > clue-multi-content-00 says "The Consumer may or may not want to receive > all the indicated captures. Therefore it can choose to receive a sub-set= of > captures indicated by the MCC." This means the consumer can choose, in a > configure message, to receive the one particular capture it wants at that > moment, for each MCC. And it can send new configure messages any time, > to change this choice. I think this would not require any SDP exchanges. > > > > If the consumer makes these choices (which still must be consistent wit= h > the advertisement), then the provider doesn't have to make any switching > choices any more. The consumer can make its choices based on its own loc= al > policy for layout and rendering. > > > > But the consumer would need some more information about current > activity in the conference in order to make these decisions. The consume= r > would need to know about audio activity, for example in the form of a "mo= st > recent talker list" or something like that, in order to make the decision= s about > which MC it wants to receive within each MCC. I don't know of any existi= ng > standard way to convey that information. It seems to me a provider could > send a "most recent talker list" to a consumer via the CLUE channel. Is > anybody interested in pursuing this idea? > > > > Mark > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Tue Oct 22 06:09:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE011E8393 for ; Tue, 22 Oct 2013 06:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOiCXBoaaQh3 for ; Tue, 22 Oct 2013 06:09:03 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1FF11E838C for ; Tue, 22 Oct 2013 06:09:03 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm4so5669813wib.0 for ; Tue, 22 Oct 2013 06:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=j+ETxs3pbGEAnV3u7PICya4Gw4LKwL/XPzoYvEpctUQ=; b=UAschtGi+AKMtDpgg9hPL5ZSehQ2vcXN9nbhnK2RUZgEhoeXvoIsSZXHmhWENi5T5x AM96O26CWBHzjRXvUlBXDCSQbW7ga21+pYyp3bgH+rpp3ansjV1kXwg0SIuz1gP5jJr3 e8h5rjO/NpBWgApp7XxlGKTZ5uslrvMbmUqo7XEWjQYs+AjmLL5Il9Vy1AunKAZmexGR x3/JHuTcrwLk5++3/muF9JyGRGePMfzPoNnw/nUkT/WjnMfld0JqRL0aSiBxl29EFuoQ SRibmP5im6w/uNWI7pOjlEjE0L5nkWJvbFH+4ofOFkZV/PewtmG3wVI4CJC0xFSm+9oN Um1A== MIME-Version: 1.0 X-Received: by 10.194.219.1 with SMTP id pk1mr9832144wjc.36.1382447342267; Tue, 22 Oct 2013 06:09:02 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Tue, 22 Oct 2013 06:09:02 -0700 (PDT) Date: Tue, 22 Oct 2013 08:09:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c1a2f0c1b25304e9541a60 Subject: [clue] No Design Team meeting Today (Oct. 22nd, 2013) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:09:04 -0000 --001a11c1a2f0c1b25304e9541a60 Content-Type: text/plain; charset=ISO-8859-1 As mentioned last week, there will be no design team meeting today. Regards, Mary. --001a11c1a2f0c1b25304e9541a60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      As mentioned last week, there will be no design team meeti= ng today. =A0

      Regards,
      Mary.=A0
      --001a11c1a2f0c1b25304e9541a60-- From mary.ietf.barnes@gmail.com Tue Oct 22 06:28:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9BF11E837C for ; Tue, 22 Oct 2013 06:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.403 X-Spam-Level: X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMmd-CGX7G50 for ; Tue, 22 Oct 2013 06:28:03 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 071A511E8388 for ; Tue, 22 Oct 2013 06:28:01 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id t60so8178148wes.12 for ; Tue, 22 Oct 2013 06:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XcOYrd+JRZGdxw80R4v7NPEoLXBn6LZdlz2TlceR6Dw=; b=SbrbSUaaU0PMvHLKI/s/4MP8ggj1gRIr1qN0Cgfj4kHhWcqFY75KByDe26VZzxY4Na e0nkGRBGt6sjQ8T/mo5IF42oGVwcAaBEAdYEfrlOE0nu+g4RAiPnBkeHun3Pvag/eqnu pzdi9lJhBOdfwTH55ZFYGlbb4VfR2ts1AmyWum1skS75SpPgSfzVYzgsz6qAIiwIW78O 6/R/IxPtpXFTys5vZ3cGLWJguEvwnPA7o8zAt29Ync3/KSaFpHW0QZrNFpG2ZuVthdCM 0FjF9pa6xP0ZlpddfKMSiryXQMg+Uj//DI3SQFTE0fvomrLhSFZuy7Vej/NLASFPQoGX dAzQ== MIME-Version: 1.0 X-Received: by 10.194.178.166 with SMTP id cz6mr2310704wjc.53.1382448481123; Tue, 22 Oct 2013 06:28:01 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Tue, 22 Oct 2013 06:28:01 -0700 (PDT) In-Reply-To: <20131021174556.32455.31080.idtracker@ietfa.amsl.com> References: <20131021174556.32455.31080.idtracker@ietfa.amsl.com> Date: Tue, 22 Oct 2013 08:28:01 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e013d1a0ca342f104e9545e7f Subject: [clue] Fwd: I-D Action: draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 13:28:04 -0000 --089e013d1a0ca342f104e9545e7f Content-Type: text/plain; charset=ISO-8859-1 HI all, I updated the FW document based on the WGLC comments from Roberta, Christian and Paul Coverdale based on these threads (where I've provided the ones most relevant from the series of discussion): http://www.ietf.org/mail-archive/web/clue/current/msg03058.html (changes 3) http://www.ietf.org/mail-archive/web/clue/current/msg02930.html (changes 2, 6) http://www.ietf.org/mail-archive/web/clue/current/msg02918.html (change 1) http://www.ietf.org/mail-archive/web/clue/current/msg02921.html (changes 4, 5) The changes are summarized in the appendix but I'll post here as well: 1) REQMT-12: Changed term "site" to "endpoint" 2) Intro: clarified that SIP based conferencing also is relevant to CLUE. 3) Intro: clarified that while CLUE doesn't dictate implementation choices, it does describe a framework for the protocol solution. 4) Clarified that mapping to use cases isn't comprehensive (i.e., only done when there is a direct correlation). 5) Added text that the requirements do not reflect all those required for the solution - i.e., the solution can provide more functionality as needed. 6) Editorial nits and clarifications - e.g., changed lc "must" to UC (REQMT-17). Folks should review the diff and post any final concerns ASAP, so that Paul can do the PROTO write-up and we can get this off to the AD for IETF Last Call. To kick that off, for the record, I am not aware of any IPR related to this document. Thanks, Mary. ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 12:45 PM Subject: I-D Action: draft-ietf-clue-telepresence-requirements-06.txt To: i-d-announce@ietf.org Cc: clue@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-requirements-06.txt Pages : 14 Date : 2013-10-21 Abstract: This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and related definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draftdirectories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --089e013d1a0ca342f104e9545e7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      HI all,

      I updated the FW document based= on the WGLC comments from Roberta, Christian and Paul Coverdale based on t= hese threads (where I've provided the ones most relevant from the serie= s of discussion):=A0


      The changes are summarized in the appendix but I'll post her= e as well:

      1) =A0REQMT-12: Changed term &= quot;site" to "endpoint" =A0

      2) =A0= Intro: clarified that SIP based conferencing also is relevant to
      =A0 =A0 =A0 CLUE.

      3) =A0Intro: clarified that= while CLUE doesn't dictate implementation
      =A0 =A0 =A0 choice= s, it does describe a framework for the protocol solution.

      4) =A0Clarified that mapping to use cases isn't comprehensive = (i.e.,
      =A0 =A0 =A0 only done when there is a direct correlation).
      <= br>
      5) Added text that the requirements do not reflect all those = required
      =A0 =A0 =A0 for the solution - i.e., the solution can pr= ovide more
      =A0 =A0 =A0 functionality as needed.

      =A06) Ed= itorial nits and clarifications - =A0e.g., changed lc "must" to U= C
      =A0 =A0 =A0 (REQMT-17).=A0


      <= /div>
      Folks should review the diff and post any final concerns ASAP, so= that Paul can do the PROTO write-up and we can get this off to the AD for = IETF Last Call. =A0To kick that off, for the record, I am not aware of any = IPR related to this document.=A0

      Thanks,
      Mary.=A0


      ---------- Forwarded message ---= -------
      From: <<= a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft= s@ietf.org>
      Date: Mon, Oct 21, 2013 at 12:45 PM
      Subject: I-D Action: draft-ietf-clue= -telepresence-requirements-06.txt
      To: i-d-announce@ietf.org
      Cc: clue@ietf.org



      A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
      =A0This draft is a work item of the ControLling mUltiple streams for tElepr= esence Working Group of the IETF.

      =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for Telepresence M= ulti-Streams
      =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Allyn Romanow
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stephen Botzko
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mary Barnes
      =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-clue-telepresence-requ= irements-06.txt
      =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
      =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-21

      Abstract:
      =A0 =A0This memo discusses the requirements for specifications that enable<= br> =A0 =A0telepresence interoperability, by describing the relationship betwee= n
      =A0 =A0multiple RTP streams. =A0In addition, the problem statement and rela= ted
      =A0 =A0definitions are also covered herein.


      The IETF datatracker status page for this draft is:
      https://datatracker.ietf.org/doc/draft-ietf-c= lue-telepresence-requirements

      There's also a htmlized version available at:
      http://tools.ietf.org/html/draft-ietf-clue-telep= resence-requirements-06

      A diff from the previous version is available at:
      http://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-clue-telepresence-requirements-06


      Please note that it may take a couple of minutes from the time of submissio= n
      until the htmlized version and diff are available at tools.ietf.org.

      Internet-Drafts are also available by anonymous FTP at:
      ftp://ftp= .ietf.org/internet-drafts/

      _______________________________________________
      I-D-Announce mailing list
      I-D-Announce@iet= f.org
      https://www.ietf.org/mailman/listinfo/i-d-announce
      Internet-Draft       directories: http://www.ietf.org/shadow.html
      or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

      --089e013d1a0ca342f104e9545e7f-- From mary.ietf.barnes@gmail.com Wed Oct 23 07:08:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBBB11E818A for ; Wed, 23 Oct 2013 07:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFrClU0gMe7Y for ; Wed, 23 Oct 2013 07:08:35 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 49EF311E838C for ; Wed, 23 Oct 2013 07:08:33 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id l12so945194wiv.2 for ; Wed, 23 Oct 2013 07:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+k5mr6LXy1zTfei2SbPN7jIxawhRDV/H2EpJ1Wxir38=; b=Q/mGZo2OrsCgDFX2hjrWzDiamrUiZE0al65dRgcqd/7Amg9/QRHa9x+KQ42LcIdBIJ NfRp6bxSC4TXsLmqUUHA21GXPd5EPLylW/KTJmVjYYalwWsRHY0FlHIYB1IZmmYgRwLR 8RaNzSQBgdUFOGRu2NZyqxBc/YDhhp/mppCnpEu7HDF7nEf8fbGjtgGq1BQtWz4v+Bp4 4RLEawvXs+qmH6xJsoF/51jXPqXCtIuKpJkzvnx7w0dydal+spzhx2a735p73jfcUjT2 kyu1NCsdaS8APNoCj2oiEJWM/nuXQvFoA1tiySg7caJwxMA4NRUhYWkFGYlYAmr3WBvo YR1w== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr1782061wic.36.1382537312365; Wed, 23 Oct 2013 07:08:32 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 07:08:32 -0700 (PDT) In-Reply-To: <5267D043.40907@cisco.com> References: <5267D043.40907@cisco.com> Date: Wed, 23 Oct 2013 09:08:32 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b62425264735d04e9690d2f Subject: [clue] Fwd: [MMUSIC] MMUSIC Draft Agenda for IETF 88 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:08:37 -0000 --047d7b62425264735d04e9690d2f Content-Type: text/plain; charset=ISO-8859-1 HI all, There are a number of documents that are/may be relevant to CLUE on the MMUSIC WG agenda on both days. I strongly encourage folks to review these drafts and attend the WG session. You might also find it helpful to re-review some of the threads of discussion on these documents on the MMUSIC WG list - e.g., Bundle. Regards, Mary. ---------- Forwarded message ---------- From: Flemming Andreasen Date: Wed, Oct 23, 2013 at 8:33 AM Subject: [MMUSIC] MMUSIC Draft Agenda for IETF 88 To: mmusic Greetings We have uploaded the MMUSIC draft agenda for IETF 88 at https://datatracker.ietf.org/meeting/88/agenda/mmusic/ and shown below as well. Please take a look and let us know if you have any questions or comments. Thanks -- Ari & Flemming (MMUSIC chairs) IETF-88, Vancouver, BC, Canada ===================================================== Multiparty Multimedia Session Control (MMUSIC) WG ===================================================== ** AGENDA ** Chairs: Flemming Andreasen (fandreas@cisco.com) Ari Keranen (ari.keranen@ericsson.com) MONDAY, November 4, 2013 (Regency B), 09:00-11:30 (150 mins) ============================================================= 9:00-9:15 Introduction and Status Update (Chairs) 9:15-9:35, draft-even-mmusic-application-token-01 (20 mins) The Session Description Protocol (SDP) Application Token Attribute 9:35-9:55, draft-nandakumar-mmusic-sdp-mux-attributes-02 (20 mins) A Framework for SDP Attributes when Multiplexing 9:55-10:25, draft-ietf-mmusic-rfc5245bis-00 (30 mins) Interactive Connectivity Establishment (ICE) 10:25-10:45, draft-thomson-mmusic-ice-webrtc-00 (20 mins) Using Interactive Connectivity Establishment (ICE) in Web Real-Time Communications (WebRTC) 10:45-11:00, draft-reddy-mmusic-ice-happy-eyeballs-03 (15 mins) Happy Eyeballs Extension for ICE 11:00-11:15, draft-martinsen-mmusic-malice-00 (15 mins) Meta-data Attribute signaLling with ICE 11:15-11:30, draft-reddy-mmusic-ice-best-interface-pcp-00 (15 mins) Improving ICE Interface Selection Using Port Control Protocol (PCP) Flow Extension WEDNESDAY, November 6, 2013 (Regency A), 13:00-15:30 (150 mins) =============================================================== 13:00-14:30, draft-ietf-mmusic-sdp-bundle-negotiation-05 (90 mins) Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers 14:30-15:00, draft-roach-mmusic-pof-pan-00 (30 mins) Using Partial Offers and Partial Answers in a Multimedia Session 15:00-15:30, draft-westerlund-avtcore-rtp-simulcast-03 (30 mins) Using Simulcast in RTP Sessions _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --047d7b62425264735d04e9690d2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      HI all,

      There are a number of documents= that are/may be relevant to CLUE on the MMUSIC WG agenda on both days. I s= trongly encourage folks to review these drafts and attend the WG session. = =A0You might also find it helpful to re-review some of the threads of discu= ssion on these documents on the MMUSIC WG list - e.g., Bundle.

      Regards,
      Mary.=A0

      ---------- Forwarded message ----------
      From: Flemming Andreasen <fandreas@cisco.com>
      Date: Wed, Oct 23, 2013 at 8:33 AM
      Subject: [MMUSIC] MMUSIC Draft Agenda= for IETF 88
      To: mmusic <mmusic@ie= tf.org>


      =20 =20 =20
      Greetings

      We have uploaded the MMUSIC draft agenda for IETF 88 at

      =A0=A0=A0 https://datatracker.ietf.org/meeting/88/agenda/mmus= ic/

      and shown below as well.

      Please take a look and let us know if you have any questions or comments.

      Thanks

      -- Ari & Flemming (MMUSIC chairs)


      =20 
                 IETF-88, Vancouver, BC, Canada

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=20

  Multiparty Multimedia Session Control (MMUSIC) WG

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

** AGENDA **

=20
Chairs: Flemming Andreasen (fandreas@cisco.com)
        Ari Keranen (ari.keranen@ericsson.com)

=20

MONDAY, November 4, 2013 (Regency B), 09:00-11:30  (150 mins)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
9:00-9:15 Introduction and Status Update (Chairs)


9:15-9:35, draft-even-mmusic-application-token-01 (20 mins)

   The Session Description Protocol (SDP) Application Token Attribute
=20

9:35-9:55, draft-nandakumar-mmusic-sdp-mux-attributes-02 (20 mins)

   A Framework for SDP Attributes when Multiplexing


9:55-10:25, draft-ietf-mmusic-rfc5245bis-00 (30 mins)

   Interactive Connectivity Establishment (ICE)


10:25-10:45, draft-thomson-mmusic-ice-webrtc-00 (20 mins)

   Using Interactive Connectivity Establishment (ICE) in Web Real-Time
   Communications (WebRTC)


10:45-11:00, draft-reddy-mmusic-ice-happy-eyeballs-03 (15 mins)

   Happy Eyeballs Extension for ICE


11:00-11:15, draft-martinsen-mmusic-malice-00 (15 mins)

   Meta-data Attribute signaLling with ICE


11:15-11:30, draft-reddy-mmusic-ice-best-interface-pcp-00 (15 mins)

   Improving ICE Interface Selection Using Port Control Protocol (PCP)
   Flow Extension



WEDNESDAY, November 6, 2013 (Regency A), 13:00-15:30 (150 mins)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

13:00-14:30, draft-ietf-mmusic-sdp-bundle-negotiation-05 (90 mins)

   Multiplexing Negotiation Using Session Description Protocol (SDP) Port N=
umbers


14:30-15:00, draft-roach-mmusic-pof-pan-00 (30 mins)

   Using Partial Offers and Partial Answers in a Multimedia Session

=20
15:00-15:30, draft-westerlund-avtcore-rtp-simulcast-03 (30 mins)=20

   Using Simulcast in RTP Sessions


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


      --047d7b62425264735d04e9690d2f-- From mary.ietf.barnes@gmail.com Wed Oct 23 07:14:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A0011E838A for ; Wed, 23 Oct 2013 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eu+3OZfw-kUc for ; Wed, 23 Oct 2013 07:14:26 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id EFB3611E83B6 for ; Wed, 23 Oct 2013 07:14:25 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id c11so892339wgh.9 for ; Wed, 23 Oct 2013 07:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OLM5eXxuOeFJAUYKSD8xrKt3ZiAZUtddYXOGfI1sbCQ=; b=r1h0TVWH52HyS7yXFw1T6TytSAnmRUJ89OvMfb/zeqI4aMhoSbWEtk3RNx3SVZeyn9 Ga0wodTwnN9x6WZbKXTrVMxv1FLh12G+eS1PDAdvAUu2NIZkv4kKvbH/jgflGlqtY+04 jpxByiPTUqrUwftPq3doqmOhxzTVVyGVZjmNe5SrqcRgnhDcBgnc4b7H37tTl6o8DOXJ 5EmNRAHkHwotuYrMNnmvFYToVeukOqWq+bwmp5GK3Ar8WYw+lbaP2aIN5jKqEvK5rOr7 T3oaZstlgMjTC9tMDVJk1fPNrWs7BORSPEVWoMrThMaQCdVQSwiVo+VIwM/sA8VYyuXT IIJw== MIME-Version: 1.0 X-Received: by 10.194.7.98 with SMTP id i2mr575962wja.84.1382537664912; Wed, 23 Oct 2013 07:14:24 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 07:14:24 -0700 (PDT) In-Reply-To: <090501cecf71$6d634740$4829d5c0$@gmail.com> References: <090501cecf71$6d634740$4829d5c0$@gmail.com> Date: Wed, 23 Oct 2013 09:14:24 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b5d4d2867e39e04e9692216 Subject: [clue] Fwd: [AVTCORE] AVTcore agenda for IETF88 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:14:26 -0000 --047d7b5d4d2867e39e04e9692216 Content-Type: text/plain; charset=ISO-8859-1 Please note that folks might want to consider attending the AVTCORE WG session as the first agenda item ( http://tools.ietf.org/id/draft-ietf-avtcore-rtp-multi-stream-01.txt) is relevant to CLUE: https://datatracker.ietf.org/meeting/88/agenda/avtcore/ Regards, Mary. ---------- Forwarded message ---------- From: Roni Even Date: Tue, Oct 22, 2013 at 4:55 PM Subject: [AVTCORE] AVTcore agenda for IETF88 To: avt@ietf.org Cc: Magnus Westerlund , payload@ietf.org Hi,**** The proposed agenda for the AVTcore session in Vancouver is uploaded. We allocated some time for Payload WG.**** Please send any comments to the chairs**** Roni Even**** AVTcore co-chair**** _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --047d7b5d4d2867e39e04e9692216 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      Please note that folks might want to consider attending th= e AVTCORE WG session as the first agenda item (http://tools.ietf.org/i= d/draft-ietf-avtcore-rtp-multi-stream-01.txt) is=A0relevant to CLUE: https:/= /datatracker.ietf.org/meeting/88/agenda/avtcore/

      Regards,
      Mary.=A0

      ---------- Forwarded message ----------
      From: Roni Even <ron.even.tlv@gmail.com>
      Date: Tue, Oct 22, 2013 at = 4:55 PM
      Subject: [AVTCORE] AVTcore agenda for IETF88
      To: avt@ietf.org
      Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, payload@ietf.org


      Hi,

      The proposed agenda for the AVTcore s= ession in Vancouver is uploaded. We allocated some time for Payload WG.<= /u>

      Please send any comments to the chairs

      Roni Even

      AVTcore co-chair


      _______________________________________________ Audio/Video Transport Core Maintenance
      avt@ietf.org
      htt= ps://www.ietf.org/mailman/listinfo/avt


      --047d7b5d4d2867e39e04e9692216-- From pkyzivat@alum.mit.edu Wed Oct 23 10:30:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C043F11E8145 for ; Wed, 23 Oct 2013 10:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WG2DrAWQI+sw for ; Wed, 23 Oct 2013 10:30:07 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A204411E81CB for ; Wed, 23 Oct 2013 10:30:05 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta05.westchester.pa.mail.comcast.net with comcast id gazl1m0010bG4ec55hW5XX; Wed, 23 Oct 2013 17:30:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id ghW41m00y3ZTu2S3PhW57q; Wed, 23 Oct 2013 17:30:05 +0000 Message-ID: <5268079C.6090106@alum.mit.edu> Date: Wed, 23 Oct 2013 13:30:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> <52661954.2010202@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D603A7C3B9@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D603A7C3B9@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382549405; bh=LULrYI7E07RBxJWEOFk1Imri8gD9fhw7GL13SLZa2+8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QLzHAPSXoWYFJ64rzWLZSEADC2hUkrYUr6XD+1vX2wrrm9kaDk0ckV+Rzh8+RKT/R vP5ruRiD5fUWkYCe5Mf7N2MpLbAJdlFKMfKbXAYoJyWbQLct8cYl5OD7B55uHOnkEw hjiL63q8uc5Zd2tKLZHnDwnyq1r5YUlXJ+24AlwqZggtkpFqFOp1NExUS7OMDILYTU F/VUDgos2ySBO5ZDQahX4MjU+OWBxf+BJJwOzWIwprYo6egQ7qVz3W2US8clEr0QiQ YvbNn/1HenNT8Cw2TJSUH554eXhtoMsndG+w4YiLD+wuGQ69Le5Yj0QEj5tNsfaQHZ Na3/E996wSZZw== Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 17:30:11 -0000 Mark, IIUC you are suggesting that the consumer might be making decisions and sending configure messages about the captures it wants to receive every time the active speaker changes. And it requires that the active speaker mapping to source capture id be available to the consumer Isn't it unrealistic to think that this could work well at that time scale? Thanks, Paul On 10/22/13 6:13 AM, Duckworth, Mark wrote: > Hi Christian, > > I understand the scenario you are talking about, where the MCU chooses the MC for the MCC based on some policy. But I think it leads to some potential problems. Like we said below, the MCU has to anticipate the rendering desires of the receiving endpoint, at least to some extent. And also the receiving endpoint might have to remap a video decoder to a different rendering location every time the MCU makes a switch. This seems like a problem for an endpoint that has particular decoders hardwired to different displays. I think these problems can be resolved if the receiver makes more explicit choices about what it wants to receive in each MCC. > > Yes, I was thinking of something like a subscribe/notify mechanism for a "recent talker list". I'm not sure it's really needed though, maybe instead the receiver can get this information from the audio streams, if the MCU sends something like the N most active audio streams. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Tuesday, October 22, 2013 2:21 AM >> To: clue@ietf.org >> Subject: Re: [clue] Example of MCC - consumer driven layout and switching >> >> Hello Mark, >> >> I guess I saw this slightly differently. Rather than chose the MC based on >> voice activity I saw that a consumer would chose the MC in the MCC based >> on the sources it wanted. It would then choose an applicable policy (i.e. most >> active, two most active, etc). The MCU would provide the appropriate MC >> based on this policy. >> >> For the "most recent talker list" it sounds like a subscribe/notify mechanism >> where the Consumer would subscribe to events and then be notified of it. Is >> this the sort of thing that you were thinking of? >> >> Regards, Christian >> >> On 12/10/2013 2:57 AM, Duckworth, Mark wrote: >>> I'm branching this topic off the MCC discussion, keeping just a small section >> of previous email. >>> >>> I have another suggestion to consider about making media switching >> decisions - see below. Has anybody else considered an idea like this? >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Robert Hansen >>>> Sent: Monday, September 30, 2013 12:43 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Example of MCC >>>> >>>>> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: >>>>>> One downside to this approach is that every change the MCU makes in >>>>>> how it assigns contributing VCs to an MCC (e.g. make a switch based >>>>>> on current talker) could result in the consumer renderer needing to >>>>>> change how it maps decoder output to display locations. I need to >>>>>> think more about if this would really be a problem or not. >>>> [RH] My issue with using the spatial coordinates of the MCC is that >>>> it requires the MCU to anticipate the rendering desires of the >>>> endpoint, as the MCU will need to advertise MCCs with spatial >>>> coordinates that allow the endpoint to do what it wants to do. My >>>> concern has always been that this may lead to huge numbers of MCCs >>>> and capture scene entries if the MCU is trying to anticipate potential >> layouts by the endpoint. >>> I agree it is good if the MCU does not have to anticipate the rendering >> (layout) desires of the endpoint consumer. So I consider if it is better if the >> consumer can make even more of the decisions, including dynamically >> selecting which source capture should be included in an MCC. draft-groves- >> clue-multi-content-00 says "The Consumer may or may not want to receive >> all the indicated captures. Therefore it can choose to receive a sub-set of >> captures indicated by the MCC." This means the consumer can choose, in a >> configure message, to receive the one particular capture it wants at that >> moment, for each MCC. And it can send new configure messages any time, >> to change this choice. I think this would not require any SDP exchanges. >>> >>> If the consumer makes these choices (which still must be consistent with >> the advertisement), then the provider doesn't have to make any switching >> choices any more. The consumer can make its choices based on its own local >> policy for layout and rendering. >>> >>> But the consumer would need some more information about current >> activity in the conference in order to make these decisions. The consumer >> would need to know about audio activity, for example in the form of a "most >> recent talker list" or something like that, in order to make the decisions about >> which MC it wants to receive within each MCC. I don't know of any existing >> standard way to convey that information. It seems to me a provider could >> send a "most recent talker list" to a consumer via the CLUE channel. Is >> anybody interested in pursuing this idea? >>> >>> Mark >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Oct 23 15:04:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E611E827E for ; Wed, 23 Oct 2013 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IunhmSLOQCFR for ; Wed, 23 Oct 2013 15:04:25 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 8035911E81EB for ; Wed, 23 Oct 2013 15:04:13 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id gcFG1m0040mv7h056m4Chu; Wed, 23 Oct 2013 22:04:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id gm4C1m00a3ZTu2S3Xm4Cmy; Wed, 23 Oct 2013 22:04:12 +0000 Message-ID: <526847DC.6060209@alum.mit.edu> Date: Wed, 23 Oct 2013 18:04:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> <525F4D0B.8090900@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382565852; bh=Wup40jWHubLpb9glCKiIqWLp2leX0dh8gt9IeuIG/5c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j81CP3Au6R9MhTMGgFrCdZ4JAqTlFJ4IzjKB+Bk5rk4mSRQj9LO5hDFI7ntc6d/0C /sxftz+jxVvTirJ8hnkuXBsG0nLPKcltJfbtGyKQC3up5/doroDFGs18UkehdvAob5 9k/ItaPHpYTRemi9bfXR5WemlYZHo2ea8VDQyoRdKhs1OUnbf4s9ez2xS+WJ8IdjAW AuKJKdUFIBHGDO6Pjpgb5U1atvWCkaKYd6cZc802DQxLXhs+M8y9gBTFKylFb8/+uE jkv5cpAHRFvY5MbiVOdciSNuIfn6IQNeGyf3rxyBqMaShJuI4yhyvlTA+Y+H99w9ls FhsEPdj+lMkAw== Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:04:29 -0000 Interesting discussion about what architecture is/isn't. Ultimately we are describing an actual protocol, and profiling some use of other protocols. That protocol references an assortment of entities, for instance scenes, capture devices, and sites. (We haven't formally defined sites, but we keep talking about them, so we ought to define.) ISTM that the high level description of those things and their relationships is an architecture for the kinds of telepresence systems we are addressing. Is that a "protocol architecture"? Or is it an architecture for the systems that the protocol is intended to support? Thanks, Paul On 10/17/13 11:42 AM, Paul Coverdale wrote: > OK, thanks for the clarification, Christian. I agree with your concern and I > support your new proposed text, with a slight change to correct the English > (addition of a semi-colon and the word "how"). > > So the new text reads: > > "CLUE will not dictate an overall Telepresence system architecture and > implementation choices; however it will describe a protocol architecture for > CLUE and how it relates to other protocols." > > > ...Paul > > > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Wednesday, October 16, 2013 10:36 PM >> To: Paul Coverdale; 'Mary Barnes' >> Cc: 'CLUE' >> Subject: Re: [clue] comments to draft-ietf-clue-telepresence- >> requirements-05.txt >> >> Hello Paul, >> >> The original paragraph was: >> " Telepresence systems of different vendors, today, can follow radically >> different architectural approaches while offering a similar user >> experience. It is not the intention of CLUE to dictate telepresence >> architectural and implementation choices. CLUE enables interoperability >> between telepresence systems by exchanging information about the >> systems' characteristics. Systems can use this information to control >> their behavior to allow for interoperability between those systems." >> >> I believe the proposal is to remove "telepresence architectural and" >> i.e. "It is not the intention of CLUE to dictate implementation >> choices". >> >> The removal of the text was the first part of the proposal the second >> part was "the CLUE framework should provide some reference architecture >> for SIP-based telepresence systems in order to let them interoperate". >> >> It's this second part that I'm trying to get to the bottom of. >> Architecture has a wide scope (e.g. as covered by F/H.TPS-Arch). >> Architecture could relate to simply where CLUE sits with other protocols >> or it could encompass defining different nodes types, endpoint >> capabilities, etc. i.e. a telepresence system architecture. The first >> sentence of the paragraph to me indicates the wider view and there >> wasn't a proposal to remove this instance. I agree with the current text >> on the view that CLUE shouldn't describe an overall "telepresence >> system" architecture. However I do think that CLUE should describe the >> protocol architecture. >> >> So to cover my concern I would propose to expand the sentence: >> "CLUE will not dictate an overall Telepresence system architecture and >> implementation choices however it will describe a protocol architecture >> for CLUE and it relates to other protocols." >> >> I think this is consistent with the framework abstract i.e. "This >> document offers a that enables devices in a >> telepresence conference to interoperate by specifying the relationships >> between multiple media streams." >> >> Regards, Christian >> >> On 17/10/2013 10:18 AM, Paul Coverdale wrote: >>> >>> I'm getting a bit confused after all the multiple in-line comments. >>> What is the proposed text that we are left with? >>> >>> ..Paul >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >>> Of *Mary Barnes >>> *Sent:* Wednesday, October 16, 2013 7:42 AM >>> *To:* Christian Groves >>> *Cc:* CLUE >>> *Subject:* Re: [clue] comments to >>> draft-ietf-clue-telepresence-requirements-05.txt >>> >>> Yet another round of responses below [MB4]. I would like to hear if >>> there's anyone else that shares Christian's concerns. If not, then I >>> will leave the text with the change based on Roberta's input, which >>> seems reasonable to me as the document editor. >>> >>> Thanks, >>> >>> Mary. >>> >>> On Tue, Oct 15, 2013 at 7:21 PM, Christian Groves >>> > >>> wrote: >>> >>> Hello Mary, >>> >>> Please see below. >>> >>> Regards, Christian >>> >>> >>> >>> >>> * about dictating architectural choices >>> In the Introduction section, "/It is not the >>> intention >>> of CLUE >>> >>> to dictate telepresence architectural and >>> implementation >>> choices./" I would propose to erase "architectural >>> choice" and >>> >>> to leave only "implementation choice". The >>> CLUE framework >>> should provide some reference architecture for >>> SIP-based >>> telepresence systems in order to let them >>> interoperate, so I >>> would not say that CLUE is not intended to dictate >>> architectural choice. >>> >>> [MB] I agree. [/MB] >>> >>> >>> [CNG] I would prefer to leave the existing text. I believe >>> that >>> was the original intention. >>> >>> [MB] I don't know what you mean by "original intention"? We have a >>> WG deliverable for a framework which does introduce >>> some architectural concepts. Clearly, we aren't prescribing >>> implementation choices. But, we do lay out a >>> model/architecture/framework for the solution. I think we >>> should stick with the text that the majority agrees with. >>> Also, please keep in mind that this is an informational >>> document, thus it's setting the context for the solution, but >>> defines nothing normative per se. >>> [/MB] >>> >>> >>> [CNG] By original intention I mean the original text "It is not >>> the intention of CLUE to dictate telepresence architectural and >>> implementation choices." This is the current text we have "stuck" >>> to. The change isn't just about removing "architectural" from the >>> requirements its also the suggested change to the framework. The >>> current framework document describes a framework for a "protocol" >>> not an overall architectural description of a SIP telepresence >>> system. I think there's enough in the framework rather than adding >>> a discussion on overall SIP telepresence system architecture. That >>> work would be non-trivial. >>> >>> [MB3] Right and removing "architectural" from the sentence is not >>> at all the same thing as saying that CLUE will define an "overall >>> SIP telepresence system architecture". The term "architectural >>> choice" really doesn't mean anything specific, so by saying we are >>> not doing that, it provides no information as to what CLUE isn't >>> doing nor does it result in this document stating that CLUE is >>> making architectural choices. However, some of us would interpret >>> architectural choices to be what protocols one uses and what >>> functional entities use the protocols and how they use those >>> protocols. That is very close to what we are doing with the >>> framework. And, as a matter of fact, that's very much what the >>> term "architecture" means in the context of IETF - e.g., The >>> Internet Architecture Board (IAB): >>> http://www.iab.org/about/iab-overview/ >>> [/MB3] >>> >>> [CNG] I'm not sure what the IAB has to do with CLUE but... I think its >>> an issue of the scope of the "architecture." >>> >>> [MB4] I was referencing the IAB's use of the term "architecture" - >>> follow the link and see the context in which the term is used in the >>> IETF. CLUE is an IETF WG thus it's entirely appropriate for an IETF WG >>> to discuss architectures. [/MB4] >>> >>> As I mentioned above its not so much the deletion of a word its >>> what is intended by that. The following sentence was "the CLUE >>> framework should provide some reference architecture for SIP-based >>> telepresence systems in order to let them interoperate" which you >>> agreed to. I have an issue if the framework becomes a general >>> document for describing a SIP telepresence system architecture. >>> For a telepresence system there is functionality beyond CLUE. >>> >>> [MB4] I think you are reading way too much into the text in this >>> section of the document. It's intended to set the context and has no >>> normative impact on anything that CLUE is doing. It's introductory >>> text. [/MB4] >>> >>> >>> If it simply describes the architecture of how CLUE relates to >>> SIP/SDP/RTP then I would agree that is in the scope of the >>> framework document. I don't think it should be a general >>> architecture of all the protocols/interface that a SIP >>> Telepresence system may use. >>> >>> With respect to the issue of "saying what we are not doing" then >>> we may as well remove the text regarding implementation choice. >>> >>> [MB4] I think the reference to "implementation" choice is important in >>> that it's highlighting the fact that you can make telepresence systems >>> interoperable without having to entirely impact a product design. As >>> you note we are not designing an entire system. [/MB4] >>> >>> >>> ..snip.. >>> >>> >>> _______________________________________________ >>> clue mailing list >>> >>> clue@ietf.org >> > >> >>> >> >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Oct 23 15:19:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B090B11E8278 for ; Wed, 23 Oct 2013 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP0F+bn8gycX for ; Wed, 23 Oct 2013 15:19:48 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 086FB11E826E for ; Wed, 23 Oct 2013 15:19:47 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id gbV11m0011c6gX85BmKnNj; Wed, 23 Oct 2013 22:19:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id gmKm1m00k3ZTu2S3jmKnBX; Wed, 23 Oct 2013 22:19:47 +0000 Message-ID: <52684B82.4090104@alum.mit.edu> Date: Wed, 23 Oct 2013 18:19:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" , Mary Barnes References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> <5238D6CA.3080500@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60333D68B@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60333D68B@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382566787; bh=zFBEMOsMxExePBMd2TN3QfKiidjHGhCVI5A/fmDnazQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PtwsME76xzLVv5XSdhpc0iHxV9j0zHGraQuq5+44lCdVJC0rObds54P4JfqHtkXZL 7QnAc5JcqsRMJlzaomnk5huJY2MC/DZ24qFYFoTN5gPdrUoSXcSSF62SILGaD+fhfE mJvZx0c0ktB4PbB0i7UThOsukSyh9EoQlam1zuCXR1JDwT5mtBpnvqd/8y6JoVtw2S UhcGOvqXo1j2HVmxfo3WqcOQluiWLK1tehoFChOah/wbDOMLuJwCHzKs4PtQR0KFh0 XaUnquGMcPpC4Fc/bnWHOw0das7JKMqXLoxKfLcTUuzrpkYcZzbN8hMyDJQfGsTEEi IujulHS000xQg== Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:19:52 -0000 I'm trying to clean up old dangling mail, and came across this one. On 9/24/13 4:46 PM, Duckworth, Mark wrote: > I always thought “site” and “endpoint” are synonymous. I don’t know > what the difference would be. I was not using “site” to refer only to > multiscreen/multicamera rooms. In most cases I think what you say will end up being right. But there are some troublesome cases that I have considered. (And discussed in the past.) Most notably: There could be a "traditional" TP room - seats for several people in front of some big screens, and some cameras pointing at them, ... There is a single system (endpoint) controlling all that equipment. This seems like a "site" to me. People in that room may have their own laptops or tablets. Those systems can have a CLUE client. They could connect directly to the same conference focus that the room endpoint connects to. They could use their private system to share presentations, and maybe to display video captures that aren't displayed in the room. (Or that are, in order to get a closer view.) These separate systems will be viewed by the MCU as separate endpoints. But should we consider them to be in a separate *site*? It might be difficult to discover that they are part of the same site. And maybe we don't need to. But it might be convenient to be able to detect that the person talking in the room is talking about the presentation being shared by the separate endpoint that he controls. Maybe this just highlights that we shouldn't use the term "site", and should instead use "endpoint" or "scene" depending on which is important. Thanks, Paul > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* Tuesday, September 17, 2013 7:21 PM > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] REMINDER!!! WGLC: > draft-ietf-clue-telepresence-requirements-05.txt > > On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > wrote: > > Mary, > > > > On 9/17/13 5:04 PM, Mary Barnes wrote: > > Yes. There are other requirements using the term site. If you look at > the definition of "endpoint", there is the following statement: > Endpoints can be anything from > multiscreen/multicamera rooms to handheld devices. > > So, I think we are using site to refer explicitly/only to > multiscreen/multicamera rooms. > > Are we? I think even then we are really talking about endpoints, but > with our design center biased towards multiscreen/multicamera rooms. > > > E.g., when we are doing "site switching", a CLUE compatible cell > phone is still going to be treated as a site, together with the > telepresence "rooms" in the session. > > [MB] Actually, we don't define "site" in the CLUE framework either (and > the word appears 89 times in the use cases). So, maybe we *should* > define site and leave most of the requirements alone. I think the word > conveys the concept well and I think we lose something if we change to > endpoint in many cases, which we should do consistently if we propose to > do so in the requirements document. [/MB] > > > I'm not aware of *anything* that is specific to > multiscreen/multicamera endpoints. > > Maybe the easiest thing to do is to just > add a parenthetical comment in that sentence like the following: > > Endpoints can be anything from > multiscreen/multicamera rooms (referred to as "sites") > to handheld devices. > > Wouldn't that confuse the definition of site switching? > > Thanks, > Paul > > Then, I do think it is appropriate to change the word "site" in > REQMT-12 > to "endpoint" as the intent of the requirement should also to > endpoints > other than multiscreen/multicamera rooms. I think the use of > "site" in > the other requirements is okay. > > Mary. > > > On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > > > >> > wrote: > > Mary, > > IIUC, you are proposing to make a change from "site" to > "endpoint" > in Reqmnt-12, and otherwise leave things alone? > > Thanks, > Paul > > > On 9/17/13 2:06 PM, Mary Barnes wrote: > > Hi Christian, > > Thanks for taking the time to review this. > Comments/responses > below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > > > > > __nteczone.com > > > >>> > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The > solution MUST > support a > means to identify > the extent of individual > video > captures in > three dimensions. > > Did we decide whether this was with respect to a > "plane of > interest" > in 3 dimensions? and/or a volume (i.e. incorporating a > depth aspect) > in 3 dimensions? It probably would be good to > clarify this > in the > requirements. > > [MB] I don't know that this particular detail matters > in the > requirements document. [/MB] > > > 2) General: At different places there are > references to > particular > use cases. However this doesn't appear to used > consistently. e.g. > Regmt-9 regarding interoperability between > endpoints using > different > numbers of streams makes references to the > heterogeneous > use case. > The heterogeneous use cases mentions different bit > rates etc, > however Reqmts-8, 7 etc don't mention the use case? It > seems to me > that if we include references to use cases that we > should > be consistent. > > [MB] Not all requirements can be mapped directly to use > cases - > e.g., > 16, 17 & 18. In the cases, where they can, we probably > should. The > references are intended to informative. [/MB] > > > 3) REQMT-12: Rather than say "..more than two " > should we use > "..more than two endpoints". We don't have a > definition for > "site". > > [MB] We don't have an explicit definition but it can > certainly be > derived from the context. We use "site" in several > other places > and just > replacing that with endpoint in those cases won't work > - e.g,. in > Section 4: "If Alice and Bob are at different sites, > Alice needs to > tell Bob about the camera and sound equipment > arrangement at her > site so > that Bob's receiver can create an accurate rendering of > her site." > That all said, I think we can replace the use of "site" > in that > requirement as that's consistent with all the other > requirements. > [/MB] > > > 4) General: Do we need to have some text in the > document that > indicates that there may be other unspecified > requirements > that may > be implemented? The framework has a number of > attributes > that aren't > mentioned as part of the requirements e.g. scene > description. Or > alternatively do we capture this by adding a generic > requirement > regarding description of the content of > captures/scenes? The > requirements are very focussed on spatial/render > aspects > rather than > information pertaining to the selection of captures. > > [MB] I do not believe so. These are the bare bones > requirements > - if we > don't have functionality to support these then we > haven't done > our job. > However, the solution can certainly define additional > functionality, > that doesn't necessarily map to a specific requirement. > The > requirements should not be specifying all the details > of the > attributes > necessary to support the use cases - that's the > objective of the > framework. Now, if you think there is a general > requirement that's > missing, certainly you can propose such. Realistically, > requirements > documents are starting points to seed the solution > work. Once the > solution is started unless the WG thinks a requirement > can't be met, > it's not necessarily productive to try to make the > requirements > document > absolutely complete. Indeed, a number of WGs actually > never publish > requirements documents, but rather just cache them in an > appendix for > historical purposes. [/MB] > > > 5) General: There seems to be a requirement in > CLUE of the > ability > to indicate how captures are related to resources. > e.g. the STS > mechanism indicates which captures may be used > together (which > indicates which ones can't be used together) and > the CSE > that groups > capture resources. This seems to be an important > aspect of > CLUE but > there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a > requirement to > justify every aspect of the solution. We don't want > to get > into having > to define capture scene entries, etc. in the > requirements. We > don't > need to backwards engineer the requirements to match the > solution. [/MB] > > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* > comments!!! :-( > > I can't advance this document without better > indication of > support from the WG. So I'm extending this > WGLC. I'll > be away > next weekend, so I will let this extension run > another two > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. > Please review > it again, > and respond either positively or negatively, > whether > you think > it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start > of WGLC for > > > draft-ietf-clue-telepresence-____requirements-05 > > > > > This WGLC will last for roughly two weeks, > ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results > from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these > requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, > internet-drafts@ietf.org > > > > __org > > > >> wrote: > > > A New Internet-Draft is available from > the on-line > Internet-Drafts > directories. > This draft is a work item of the > ControLling > mUltiple > streams for > tElepresence Working Group of the IETF. > > Title : Requirements for > Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : > > draft-ietf-clue-telepresence-____requirements-05.txt > > > > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the > requirements for a > specification that enables > telepresence interoperability, by > describing the > relationship between > multiple RTP streams. In > addition, the > problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for > this draft is: > > https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements > > > > > > > > > > > > > > There's also a htmlized version > available at: > > http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05 > > > > > > > > > > > > A diff from the previous version is > available at: > > http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05 > > > > > > > > > > > > > > > Please note that it may take a couple of > minutes from > the time of > submission > until the htmlized version and diff are > available at > > tools.ietf.org > . > > > > > Internet-Drafts are also available by > anonymous > FTP at: > > ftp://ftp.ietf.org/internet-____drafts/ > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > From mary.ietf.barnes@gmail.com Wed Oct 23 16:14:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2845111E8244 for ; Wed, 23 Oct 2013 16:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LnZAD+g3tLp for ; Wed, 23 Oct 2013 16:14:33 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7948211E8294 for ; Wed, 23 Oct 2013 16:14:25 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hn9so1690081wib.17 for ; Wed, 23 Oct 2013 16:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KCRQR9v3csry55TJ/vTSrOMD2ZHoIfie0FZWf2cMMWo=; b=qMWeRbDfiPjcDitotppOJsa/3hDXfTIKBj9zN3c7ubXy+egNKNGs1LHPtN9DaWlvu1 GWAFu2dPGWNnxVps9QzSKrSLbsTzFVnzu90NIPeFaz6+Cj2OY17TGFXaEzR1o5oA0zfU SeILkT9XyIoNdZqMGBgLhPgPbti799ddqrbQoCB0H7l7ja331Z09Pio2A44C4hzU5pbx ogviUJW9WPecaRYR3rUSp6EDZbx0LSqmPUFTRC5U3FRFCL8fLCSB/rVFgNv97gn7kQZo GI7bha3E+qVKUzPYtVmThCW9KXoFYgg5d6rxU5FjD4Ba6omcb+dKsNZdUTTtkfQb/7nk I3Fw== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr3532004wic.36.1382570064620; Wed, 23 Oct 2013 16:14:24 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Wed, 23 Oct 2013 16:14:24 -0700 (PDT) In-Reply-To: <52684B82.4090104@alum.mit.edu> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> <5238D6CA.3080500@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60333D68B@CRPMBOXPRD07.polycom.com> <52684B82.4090104@alum.mit.edu> Date: Wed, 23 Oct 2013 18:14:24 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b6242529432d404e970adb5 Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:14:36 -0000 --047d7b6242529432d404e970adb5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Oct 23, 2013 at 5:19 PM, Paul Kyzivat wrote= : > I'm trying to clean up old dangling mail, and came across this one. > > > On 9/24/13 4:46 PM, Duckworth, Mark wrote: > >> I always thought =93site=94 and =93endpoint=94 are synonymous. I don=92= t know >> what the difference would be. I was not using =93site=94 to refer only = to >> multiscreen/multicamera rooms. >> > > In most cases I think what you say will end up being right. > But there are some troublesome cases that I have considered. (And > discussed in the past.) Most notably: > > There could be a "traditional" TP room - seats for several people in fron= t > of some big screens, and some cameras pointing at them, ... > There is a single system (endpoint) controlling all that equipment. > This seems like a "site" to me. > > People in that room may have their own laptops or tablets. Those systems > can have a CLUE client. They could connect directly to the same conferenc= e > focus that the room endpoint connects to. They could use their private > system to share presentations, and maybe to display video captures that > aren't displayed in the room. (Or that are, in order to get a closer view= .) > > These separate systems will be viewed by the MCU as separate endpoints. > But should we consider them to be in a separate *site*? > > It might be difficult to discover that they are part of the same site. An= d > maybe we don't need to. But it might be convenient to be able to detect > that the person talking in the room is talking about the presentation bei= ng > shared by the separate endpoint that he controls. > > Maybe this just highlights that we shouldn't use the term "site", and > should instead use "endpoint" or "scene" depending on which is important. > [MB] Exactly. And, I used the former "endpoint" in resolving the issue that Christian raised. I think we got a little wrapped around the axle on this one as I don't think it matters in the context we're working - i.e., I don't think it's a problem for the framework, which uses primarily endpoint. "site" is only used in the context of "site-switching" in the framework - i.e,. 7.2.2 of the framework. Note that "scene" is already being used in that context for "Scene switch policy" - i.e., "site switch" or "segment switch". However, I think the term "site" is quite clear in that context, so I think we may be able to leave all that as is. We spent a lot of time early on coming up with terms for these things, so I do think we need to be extremely careful about making changes at this juncture. [/MB] > > Thanks, > Paul > > Mark >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> >> Of *Mary Barnes >> *Sent:* Tuesday, September 17, 2013 7:21 PM >> *To:* Paul Kyzivat >> *Cc:* CLUE >> *Subject:* Re: [clue] REMINDER!!! WGLC: >> >> draft-ietf-clue-telepresence-**requirements-05.txt >> >> On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > **> wrote: >> >> Mary, >> >> >> >> On 9/17/13 5:04 PM, Mary Barnes wrote: >> >> Yes. There are other requirements using the term site. If you look >> at >> the definition of "endpoint", there is the following statement: >> Endpoints can be anything from >> multiscreen/multicamera rooms to handheld devices. >> >> So, I think we are using site to refer explicitly/only to >> multiscreen/multicamera rooms. >> >> Are we? I think even then we are really talking about endpoints, but >> with our design center biased towards multiscreen/multicamera rooms. >> >> >> E.g., when we are doing "site switching", a CLUE compatible cell >> phone is still going to be treated as a site, together with the >> telepresence "rooms" in the session. >> >> [MB] Actually, we don't define "site" in the CLUE framework either (and >> the word appears 89 times in the use cases). So, maybe we *should* >> define site and leave most of the requirements alone. I think the word >> conveys the concept well and I think we lose something if we change to >> endpoint in many cases, which we should do consistently if we propose to >> do so in the requirements document. [/MB] >> >> >> I'm not aware of *anything* that is specific to >> multiscreen/multicamera endpoints. >> >> Maybe the easiest thing to do is to just >> add a parenthetical comment in that sentence like the following: >> >> Endpoints can be anything from >> multiscreen/multicamera rooms (referred to as "sites") >> to handheld devices. >> >> Wouldn't that confuse the definition of site switching? >> >> Thanks, >> Paul >> >> Then, I do think it is appropriate to change the word "site" in >> REQMT-12 >> to "endpoint" as the intent of the requirement should also to >> endpoints >> other than multiscreen/multicamera rooms. I think the use of >> "site" in >> the other requirements is okay. >> >> Mary. >> >> >> On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat >> >> >> **>> >> >> wrote: >> >> Mary, >> >> IIUC, you are proposing to make a change from "site" to >> "endpoint" >> in Reqmnt-12, and otherwise leave things alone? >> >> Thanks, >> Paul >> >> >> On 9/17/13 2:06 PM, Mary Barnes wrote: >> >> Hi Christian, >> >> Thanks for taking the time to review this. >> Comments/responses >> below [MB]. >> >> Mary. >> >> >> On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves >> > >> > >> >> >> >> >> >> > __nt**eczone.com = < >> http://nteczone.com> >> >> >> >> >> >>>> >> >> wrote: >> >> Hello, >> >> Here are my comments to the WGLC: >> >> 1) Reqmt-1D - With regards to reqmt-1d: The >> solution MUST >> support a >> means to identify >> the extent of individual >> video >> captures in >> three dimensions. >> >> Did we decide whether this was with respect to a >> "plane of >> interest" >> in 3 dimensions? and/or a volume (i.e. >> incorporating a >> depth aspect) >> in 3 dimensions? It probably would be good to >> clarify this >> in the >> requirements. >> >> [MB] I don't know that this particular detail matters >> in the >> requirements document. [/MB] >> >> >> 2) General: At different places there are >> references to >> particular >> use cases. However this doesn't appear to used >> consistently. e.g. >> Regmt-9 regarding interoperability between >> endpoints using >> different >> numbers of streams makes references to the >> heterogeneous >> use case. >> The heterogeneous use cases mentions different bit >> rates etc, >> however Reqmts-8, 7 etc don't mention the use case= ? >> It >> seems to me >> that if we include references to use cases that we >> should >> be consistent. >> >> [MB] Not all requirements can be mapped directly to use >> cases - >> e.g., >> 16, 17 & 18. In the cases, where they can, we probably >> should. The >> references are intended to informative. [/MB] >> >> >> 3) REQMT-12: Rather than say "..more than two >> " >> should we use >> "..more than two endpoints". We don't have a >> definition for >> "site". >> >> [MB] We don't have an explicit definition but it can >> certainly be >> derived from the context. We use "site" in several >> other places >> and just >> replacing that with endpoint in those cases won't work >> - e.g,. in >> Section 4: "If Alice and Bob are at different sites, >> Alice needs to >> tell Bob about the camera and sound equipment >> arrangement at her >> site so >> that Bob's receiver can create an accurate rendering of >> her site." >> That all said, I think we can replace the use of "site" >> in that >> requirement as that's consistent with all the other >> requirements. >> [/MB] >> >> >> 4) General: Do we need to have some text in the >> document that >> indicates that there may be other unspecified >> requirements >> that may >> be implemented? The framework has a number of >> attributes >> that aren't >> mentioned as part of the requirements e.g. scene >> description. Or >> alternatively do we capture this by adding a gener= ic >> requirement >> regarding description of the content of >> captures/scenes? The >> requirements are very focussed on spatial/render >> aspects >> rather than >> information pertaining to the selection of capture= s. >> >> [MB] I do not believe so. These are the bare bones >> requirements >> - if we >> don't have functionality to support these then we >> haven't done >> our job. >> However, the solution can certainly define additiona= l >> functionality, >> that doesn't necessarily map to a specific requirement. >> The >> requirements should not be specifying all the details >> of the >> attributes >> necessary to support the use cases - that's the >> objective of the >> framework. Now, if you think there is a general >> requirement that's >> missing, certainly you can propose such. Realistically, >> requirements >> documents are starting points to seed the solution >> work. Once the >> solution is started unless the WG thinks a requirement >> can't be met, >> it's not necessarily productive to try to make the >> requirements >> document >> absolutely complete. Indeed, a number of WGs actually >> never publish >> requirements documents, but rather just cache them in a= n >> appendix for >> historical purposes. [/MB] >> >> >> 5) General: There seems to be a requirement in >> CLUE of the >> ability >> to indicate how captures are related to resources. >> e.g. the STS >> mechanism indicates which captures may be used >> together (which >> indicates which ones can't be used together) and >> the CSE >> that groups >> capture resources. This seems to be an important >> aspect of >> CLUE but >> there doesn't appear to be a requirement driving i= t. >> >> [MB] As I mentioned previously, we don't need to have a >> requirement to >> justify every aspect of the solution. We don't want >> to get >> into having >> to define capture scene entries, etc. in the >> requirements. We >> don't >> need to backwards engineer the requirements to match th= e >> solution. [/MB] >> >> >> Regards, Christian >> >> >> On 16/09/2013 5:32 AM, Paul Kyzivat wrote: >> >> We started WGLC on the requirements two weeks >> ago. >> It has run for two weeks, and there have been >> *NO* >> comments!!! :-( >> >> I can't advance this document without better >> indication of >> support from the WG. So I'm extending this >> WGLC. I'll >> be away >> next weekend, so I will let this extension run >> another two >> weeks, ending Sunday Sept 29. >> >> We NEED NEED NEED your comments on this. >> Please review >> it again, >> and respond either positively or negatively, >> whether >> you think >> it is ready to progress. >> >> Thanks, >> Paul >> >> On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> >> With this message I'm announcing the start >> of WGLC for >> >> >> draft-ietf-clue-telepresence-_**___requirements-05 >> >> >> >> >> This WGLC will last for roughly two weeks, >> ending at >> midnight GMT on >> Sunday September 15. >> >> It is important to have decisive results >> from a WGLC. >> (Silence doesn't do it.) >> So please, take a last careful look at the= se >> requirements >> and comment. >> If you like these as they are, please say >> so. >> >> Thanks, >> Paul (as co-chair) >> >> On 8/30/13 6:39 PM, >> internet-drafts@ietf.org >> > >> >> >> >> >> > **__org >> >> >> >> >>> >> wrote: >> >> >> A New Internet-Draft is available from >> the on-line >> Internet-Drafts >> directories. >> This draft is a work item of the >> ControLling >> mUltiple >> streams for >> tElepresence Working Group of the IETF= . >> >> Title : Requirements fo= r >> Telepresence >> Multi-Streams >> Author(s) : Allyn Romanow >> Stephen >> Botzko >> Mary Barne= s >> Filename : >> >> draft-ietf-clue-telepresence-_**___requirements-05.txt >> >> >> >> Pages : 13 >> Date : 2013-08-30 >> >> Abstract: >> This memo discusses the >> requirements for a >> specification that enables >> telepresence interoperability, by >> describing the >> relationship between >> multiple RTP streams. In >> addition, the >> problem >> statement and >> definitions are also covered >> herein. >> >> >> The IETF datatracker status page for >> this draft is: >> >> https://datatracker.ietf.org/_**___doc/draft-ietf-clue-____** >> telepresence-requirements >> >> > telepresence-requirements >> > >> >> >> >> >> >> > telepresence-requirements >> >> > telepresence-requirements >> >> >> >> >> >> There's also a htmlized version >> available at: >> >> http://tools.ietf.org/html/___**_draft-ietf-clue-telepresence-** >> ____requirements-05 >> >> > _requirements-05 >> > >> >> >> >> >> >> > _requirements-05 >> >> > requirements-05 >> >> >> >> A diff from the previous version is >> available at: >> >> http://www.ietf.org/rfcdiff?__**__url2=3Ddraft-ietf-clue-____** >> telepresence-requirements-05 >> >> > telepresence-requirements-05 >> > >> >> >> >> >> >> > telepresence-requirements-05 >> >> > telepresence-requirements-05 >> >> >> >> >> >> >> Please note that it may take a couple = of >> minutes from >> the time of >> submission >> until the htmlized version and diff ar= e >> available at >> >> tools.ietf.org >> . >> >> >> >> >> Internet-Drafts are also available by >> anonymous >> FTP at: >> >> ftp://ftp.ietf.org/internet-__**__drafts/ >> >> > >> > _drafts/ >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org > > > clue@ietf.org> >> >> >> >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org > > > clue@ietf.org> >> >> >> >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> > __listinfo/clue >> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org > > > clue@ietf.org> >> >> >> >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> ______________________________** >> _____________________ >> clue mailing list >> clue@ietf.org > > > clue@ietf.org> >> >> >> >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> > --047d7b6242529432d404e970adb5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



      On Wed, Oct 23, 2013 at 5:19 PM, Paul Kyzivat <= ;pkyzivat@alum.m= it.edu> wrote:
      I'm trying to clean up old dangling mail= , and came across this one.


      On 9/24/13 4:46 PM, Duckworth, Mark wrote:
      I always thought =93site=94 and =93endpoint=94 are synonymous. =A0I don=92t= know
      what the difference would be. =A0I was not using =93site=94 to refer only t= o
      multiscreen/multicamera rooms.

      In most cases I think what you say will end up being right.
      But there are some troublesome cases that I have considered. (And discussed= in the past.) Most notably:

      There could be a "traditional" TP room - seats for several people= in front of some big screens, and some cameras pointing at them, ...
      There is a single system (endpoint) controlling all that equipment.
      This seems like a "site" to me.

      People in that room may have their own laptops or tablets. Those systems ca= n have a CLUE client. They could connect directly to the same conference fo= cus that the room endpoint connects to. They could use their private system= to share presentations, and maybe to display video captures that aren'= t displayed in the room. (Or that are, in order to get a closer view.)

      These separate systems will be viewed by the MCU as separate endpoints. But= should we consider them to be in a separate *site*?

      It might be difficult to discover that they are part of the same site. And = maybe we don't need to. But it might be convenient to be able to detect= that the person talking in the room is talking about the presentation bein= g shared by the separate endpoint that he controls.

      Maybe this just highlights that we shouldn't use the term "site&qu= ot;, and should instead use "endpoint" or "scene" depen= ding on which is important.
      [MB] Exactly. And, I= used the former "endpoint" in resolving the issue that Christian= raised. =A0I think we got a little wrapped around the axle on this one as = I don't think it matters in the context we're working - i.e., I don= 't think it's a problem for the framework, which uses primarily end= point. =A0"site" is only used in the context of "site-switch= ing" in the framework - i.e,. 7.2.2 of the framework. =A0Note that &qu= ot;scene" is already being used in that context for "Scene switch= policy" - i.e., "site switch" or "segment switch"= . =A0However, I think the term "site" is quite clear in that cont= ext, so I think we may be able to leave all that as is. =A0We spent a lot o= f time early on coming up with terms for these things, so I do think we nee= d to be extremely careful about making changes at this juncture. =A0[/MB]

      =A0 =A0 =A0 =A0 Thanks,
      =A0 =A0 =A0 =A0 Paul

      Mark

      *From:*clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf

      Of *Mary Barnes
      *Sent:* Tuesday, September 17, 2013 7:21 PM
      *To:* Paul Kyzivat
      *Cc:* CLUE
      *Subject:* Re: [clue] REMINDER!!! WGLC:

      draft-ietf-clue-telepresence-requirements-05.txt

      On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
      <= div class=3D"h5"> <mailto:pkyzi= vat@alum.mit.edu>> wrote:

      =A0 =A0 Mary,



      =A0 =A0 On 9/17/13 5:04 PM, Mary Barnes wrote:

      =A0 =A0 Yes. =A0There are other requirements using the term site. =A0If you= look at
      =A0 =A0 the definition of "endpoint", there is the following stat= ement:
      =A0 =A0 Endpoints can be anything from
      =A0 =A0 multiscreen/multicamera rooms to handheld devices.

      =A0 =A0 So, I think we are using site to refer explicitly/only to
      =A0 =A0 multiscreen/multicamera rooms.

      =A0 =A0 Are we? I think even then we are really talking about endpoints, bu= t
      =A0 =A0 with our design center biased towards multiscreen/multicamera rooms= .


      =A0 =A0 E.g., when we are doing "site switching", a CLUE compatib= le cell
      =A0 =A0 phone is still going to be treated as a site, together with the
      =A0 =A0 telepresence "rooms" in the session.

      [MB] Actually, we don't define "site" in the CLUE framework e= ither (and
      the word appears 89 times in the use cases). =A0 So, maybe we *should*
      define site and leave most of the requirements alone. =A0I think the word conveys the concept well and I think we lose something if we change to
      endpoint in many cases, which we should do consistently if we propose to do so in the requirements document. =A0 =A0[/MB]


      =A0 =A0 I'm not aware of *anything* that is specific to
      =A0 =A0 multiscreen/multicamera endpoints.

      =A0 =A0 =A0 =A0 Maybe the easiest thing to do is to just
      =A0 =A0 =A0 =A0 add a parenthetical comment in that sentence like the follo= wing:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Endpoints can be anything from
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiscreen/multicamera rooms (referred to = as "sites")
      =A0 =A0 =A0 =A0 to handheld devices.

      =A0 =A0 Wouldn't that confuse the definition of site switching?

      =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

      =A0 =A0 =A0 =A0 Then, I do think it is appropriate to change the word "= ;site" in
      =A0 =A0 =A0 =A0 REQMT-12
      =A0 =A0 =A0 =A0 to "endpoint" as the intent of the requirement sh= ould also to
      =A0 =A0 =A0 =A0 endpoints
      =A0 =A0 =A0 =A0 other than multiscreen/multicamera rooms. =A0I think the us= e of
      =A0 =A0 =A0 =A0 "site" in
      =A0 =A0 =A0 =A0 the other requirements is okay.

      =A0 =A0 =A0 =A0 Mary.


      =A0 =A0 =A0 =A0 On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat
      =A0 =A0 =A0 =A0 <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>

      =A0 =A0 =A0 =A0 <mailto:pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>&g= t;

      =A0 =A0 =A0 =A0 wrote:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary,

      =A0 =A0 =A0 =A0 =A0 =A0 =A0IIUC, you are proposing to make a change from &q= uot;site" to
      =A0 =A0 =A0 =A0 "endpoint"
      =A0 =A0 =A0 =A0 =A0 =A0 =A0in Reqmnt-12, and otherwise leave things alone?<= br>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul


      =A0 =A0 =A0 =A0 =A0 =A0 =A0On 9/17/13 2:06 PM, Mary Barnes wrote:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hi Christian,

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks for taking the time to review thi= s.
      =A0 =A0 =A0 =A0 Comments/responses
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0below [MB].

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary.


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On Mon, Sep 16, 2013 at 11:10 PM, Christ= ian Groves
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<Christian.Groves@nteczone.com
      =A0 =A0 =A0 =A0 <mailto:Christian.Groves@nteczone.com>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:Christian.Groves@nteczone.com<= /a>
      =A0 =A0 =A0 =A0 <mailto:      Christian.Groves@nteczone.com>>

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:Christian.Groves@
      =A0 =A0 =A0 =A0 <mailto:Christian.Groves@>__nteczone.com <http://nteczone.com>


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:Christian.Groves@nteczone.com<= /a>
      =A0 =A0 =A0 =A0 <mailto:Christian.Groves@nteczone.com>>>>=

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0wrote:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hello,

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Here are my comments to the WGL= C:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1) Reqmt-1D - With regards to r= eqmt-1d: The
      =A0 =A0 =A0 =A0 solution MUST
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support a
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 means to identify
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 the extent of individual
      =A0 =A0 =A0 =A0 video
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0captures in
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 three dimensions.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Did we decide whether this was = with respect to a
      =A0 =A0 =A0 =A0 "plane of
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interest"
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in 3 dimensions? and/or a volum= e (i.e. incorporating a
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0depth aspect)
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 in 3 dimensions? It probably wo= uld be good to
      =A0 =A0 =A0 =A0 clarify this
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0in the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 requirements.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] I don't know that this particul= ar detail matters
      =A0 =A0 =A0 =A0 in the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirements document. =A0[/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 2) General: At different places= there are
      =A0 =A0 =A0 =A0 references to
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0particular
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 use cases. However this doesn&#= 39;t appear to used
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0consistently. e.g.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regmt-9 regarding interoperabil= ity between
      =A0 =A0 =A0 =A0 endpoints using
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0different
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 numbers of streams makes refere= nces to the
      =A0 =A0 =A0 =A0 heterogeneous
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0use case.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The heterogeneous use cases men= tions different bit
      =A0 =A0 =A0 =A0 rates etc,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 however Reqmts-8, 7 etc don'= ;t mention the use case? It
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0seems to me
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that if we include references t= o use cases that we
      =A0 =A0 =A0 =A0 should
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be consistent.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] Not all requirements can be mapped = directly to use
      =A0 =A0 =A0 =A0 cases -
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0e.g.,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A016, 17 & 18. In the cases, where the= y can, we probably
      =A0 =A0 =A0 =A0 should. The
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0references are intended to informative. = [/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3) REQMT-12: Rather than say &q= uot;..more than two <sites>"
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should we use
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "..more than two endpoints= ". We don't have a
      =A0 =A0 =A0 =A0 definition for
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"site".

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] We don't have an explicit defin= ition but it can
      =A0 =A0 =A0 =A0 certainly be
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0derived from the context. We use "s= ite" in several
      =A0 =A0 =A0 =A0 other places
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and just
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0replacing that with endpoint in those ca= ses won't work
      =A0 =A0 =A0 =A0 - e.g,. in
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 4: =A0"If Alice and Bob are= at different sites,
      =A0 =A0 =A0 =A0 Alice needs to
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tell Bob about the camera and sound equi= pment
      =A0 =A0 =A0 =A0 arrangement at her
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0site so
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that Bob's receiver can create an ac= curate rendering of
      =A0 =A0 =A0 =A0 her site."
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That all said, I think we can replace th= e use of "site"
      =A0 =A0 =A0 =A0 in that
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirement as that's consistent wit= h all the other
      =A0 =A0 =A0 =A0 requirements.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 4) General: Do we need to have = some text in the
      =A0 =A0 =A0 =A0 document that
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicates that there may be oth= er unspecified
      =A0 =A0 =A0 =A0 requirements
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that may
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 be implemented? The framework h= as a number of
      =A0 =A0 =A0 =A0 attributes
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that aren't
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mentioned as part of the requir= ements e.g. scene
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0description. Or
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 alternatively do we capture thi= s by adding a generic
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirement
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 regarding description of the co= ntent of
      =A0 =A0 =A0 =A0 captures/scenes? The
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 requirements are very focussed = on spatial/render
      =A0 =A0 =A0 =A0 aspects
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rather than
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 information pertaining to the s= election of captures.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] I do not believe so. =A0These are t= he bare bones
      =A0 =A0 =A0 =A0 requirements
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- if we
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0don't have functionality to support = these then we
      =A0 =A0 =A0 =A0 haven't done
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0our job.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 However, the solution can certainly= define additional
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0functionality,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that doesn't necessarily map to a sp= ecific requirement.
      =A0 =A0 =A0 =A0 =A0 The
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirements should not be specifying al= l the details
      =A0 =A0 =A0 =A0 of the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0attributes
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0necessary to support the use cases - tha= t's the
      =A0 =A0 =A0 =A0 objective of the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0framework. Now, if you think there is a = general
      =A0 =A0 =A0 =A0 requirement that's
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0missing, certainly you can propose such.= Realistically,
      =A0 =A0 =A0 =A0 requirements
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0documents are starting points to seed th= e solution
      =A0 =A0 =A0 =A0 work. Once the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solution is started unless the WG thinks= a requirement
      =A0 =A0 =A0 =A0 can't be met,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it's not necessarily productive to t= ry to make the
      =A0 =A0 =A0 =A0 requirements
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0document
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0absolutely complete. =A0Indeed, a number= of WGs actually
      =A0 =A0 =A0 =A0 never publish
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirements documents, but rather just = cache them in an
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0appendix for
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0historical purposes. [/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5) General: There seems to be a= requirement in
      =A0 =A0 =A0 =A0 CLUE of the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ability
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 to indicate how captures are re= lated to resources.
      =A0 =A0 =A0 =A0 e.g. the STS
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mechanism indicates which captu= res may be used
      =A0 =A0 =A0 =A0 together (which
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 indicates which ones can't = be used together) and
      =A0 =A0 =A0 =A0 the CSE
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0that groups
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 capture resources. This seems t= o be an important
      =A0 =A0 =A0 =A0 aspect of
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CLUE but
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 there doesn't appear to be = a requirement driving it.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[MB] As I mentioned previously, we don&#= 39;t need to have a
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirement to
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0justify every aspect of the solution. = =A0 We don't want
      =A0 =A0 =A0 =A0 to get
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0into having
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0to define capture scene entries, etc. in= the
      =A0 =A0 =A0 =A0 requirements. =A0 We
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0don't
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0need to backwards engineer the requireme= nts to match the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0solution. =A0[/MB]


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Regards, Christian


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 16/09/2013 5:32 AM, Paul Kyz= ivat wrote:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We started WGLC on the = requirements two weeks ago.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It has run for two week= s, and there have been *NO*
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0comments!!! :-(

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I can't advance thi= s document without better
      =A0 =A0 =A0 =A0 indication of
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 support from the WG. So= I'm extending this
      =A0 =A0 =A0 =A0 WGLC. I'll
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be away
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 next weekend, so I will= let this extension run
      =A0 =A0 =A0 =A0 another two
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 weeks, ending Sunday Se= pt 29.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We NEED NEED NEED your = comments on this.
      =A0 =A0 =A0 =A0 Please review
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it again,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and respond either posi= tively or negatively,
      =A0 =A0 =A0 =A0 whether
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0you think
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it is ready to progress= .

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 9/2/13 3:50 PM, Paul= Kyzivat wrote:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 With this messa= ge I'm announcing the start
      =A0 =A0 =A0 =A0 of WGLC for


      =A0 =A0 =A0 =A0 =A0 draft-ietf-clue-telepresence-____requirements-05=




      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This WGLC will = last for roughly two weeks,
      =A0 =A0 =A0 =A0 ending at
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 midnight GMT on=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sunday Septembe= r 15.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 It is important= to have decisive results
      =A0 =A0 =A0 =A0 from a WGLC.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (Silence doesn&= #39;t do it.)
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 So please, take= a last careful look at these
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0requirements
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and comment. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If you like the= se as they are, please say so.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Tha= nks,
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pau= l (as co-chair)

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 8/30/13 6:39= PM,
      =A0 =A0 =A0 =A0 internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf.org
      =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf<= /a>.
      =A0 =A0 =A0 =A0 <mailto:      internet-drafts@ietf.>__org


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf.org
      =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>>> wrote:


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A New I= nternet-Draft is available from
      =A0 =A0 =A0 =A0 the on-line
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Interne= t-Drafts
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 directo= ries.
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= This draft is a work item of the
      =A0 =A0 =A0 =A0 ControLling
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mUltiple
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 streams= for
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tElepre= sence Working Group of the IETF.

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Title =A0 =A0 =A0 =A0 =A0 : Requirements for
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Telepresence
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multi-S= treams
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Author(s) =A0 =A0 =A0 : Allyn Romanow
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stephen Botzko
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Mary Barnes
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Filename =A0 =A0 =A0 =A0:

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-clue-telepresence-____= requirements-05.txt



      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Pages =A0 =A0 =A0 =A0 =A0 : 13
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-30

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Abstrac= t:
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0This memo discusses the
      =A0 =A0 =A0 =A0 requirements for a
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specifi= cation that enables
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0telepresence interoperability, by
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0describing the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relatio= nship between
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0multiple RTP streams. =A0In
      =A0 =A0 =A0 =A0 addition, the
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0problem
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stateme= nt and
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0definitions are also covered herein.


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The IET= F datatracker status page for
      =A0 =A0 =A0 =A0 this draft is:

      =A0 =A0 =A0 =A0 https://datatracker.i= etf.org/____doc/draft-ietf-clue-____telepresence-requirements=

      =A0 =A0 =A0 =A0 <https://datatracker.i= etf.org/__doc/draft-ietf-clue-__telepresence-requirements= >





      =A0 =A0 =A0 =A0 <https://datatracker.i= etf.org/__doc/draft-ietf-clue-__telepresence-requirements=

      =A0 =A0 =A0 =A0 <https://datatracker.ietf.= org/doc/draft-ietf-clue-telepresence-requirements>>=



      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 There&#= 39;s also a htmlized version
      =A0 =A0 =A0 =A0 available at:

      =A0 =A0 =A0 =A0 http://tools.ietf.org/ht= ml/____draft-ietf-clue-telepresence-____requirements-05
      =A0 =A0 =A0 =A0 <http://tools.ietf.org/ht= ml/__draft-ietf-clue-telepresence-__requirements-05>




      =A0 =A0 =A0 =A0 <http://tools.ietf.org/ht= ml/__draft-ietf-clue-telepresence-__requirements-05

      =A0 =A0 =A0 =A0 <http://tools.ietf.org/html/<= u>draft-ietf-clue-telepresence-requirements-05>>

      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A diff = from the previous version is
      =A0 =A0 =A0 =A0 available at:

      =A0 =A0 =A0 =A0 http://www.ietf.= org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepresence-requi= rements-05

      =A0 =A0 =A0 =A0 <http://www.ietf.= org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requireme= nts-05>





      =A0 =A0 =A0 =A0 <http://www.ietf.= org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requireme= nts-05

      =A0 =A0 =A0 =A0 <http://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirements-05>>




      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Please = note that it may take a couple of
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0minutes from
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the tim= e of
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 submiss= ion
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 until t= he htmlized version and diff are
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0available at

      =A0 =A0 =A0 =A0       tools.i= etf.org <http://= tools.ietf.org> <http://tools.ietf.org>
      =A0 =A0 =A0 =A0 <htt= p://tools.ietf.org>.




      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Interne= t-Drafts are also available by
      =A0 =A0 =A0 =A0 anonymous
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FTP at:

      =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-____drafts/
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-__drafts= />
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <ftp://ftp.= ietf.org/internet-__drafts/
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-drafts/>>


      =A0 =A0 =A0 =A0 =A0 ________________________________________________= ___
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue ma= iling list
      =A0 =A0 =A0 =A0       clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto:clue@ietf.org>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>
      <= br> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/= __listinfo/clue>

      =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/li= stinfo/clue>>



      =A0 =A0 =A0 =A0 =A0 ________________________________________________= ___
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing li= st
      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto:clue@ietf.org>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>
      <= br> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/= __listinfo/clue>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www= .ietf.org/mailman/__listinfo/clue
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/li= stinfo/clue>>



      =A0 =A0 =A0 =A0 =A0 ________________________________________________= ___
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing list
      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto:clue@ietf.org>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>
      <= br> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/= __listinfo/clue>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.or= g/mailman/__listinfo/clue
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/li= stinfo/clue>>


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ______________________________<= u>      _____________________
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing list
      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>> <mailto:clue@ietf.org <mailto:clue@ietf.org>
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:clue@ietf.org <mailto:clue@ietf.org>>>
      <= br> =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/= __listinfo/clue>


      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailma= n/__listinfo/clue
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/li= stinfo/clue>>




      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________= ________________
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
      =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
      =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/li= stinfo/clue>


      =A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________________= ________
      =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
      =A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
      =A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
      =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
      =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/listinfo/c= lue>



      --047d7b6242529432d404e970adb5-- From mary.ietf.barnes@gmail.com Thu Oct 24 07:14:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E6021F99E8 for ; Thu, 24 Oct 2013 07:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZZKb89VVxod for ; Thu, 24 Oct 2013 07:14:38 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id BA57111E830C for ; Thu, 24 Oct 2013 07:14:35 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id q59so2420586wes.11 for ; Thu, 24 Oct 2013 07:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MOW3ivA++orA2OyO+46VSZnCM4N5i50ju9RPa67giPE=; b=bkFgIBX2w9HWhQf5jlu/37LeydjP0PvUcKM/ManHmXR+V1Jq2cz20TbbrL3OVJE8nN mUCmIxEHnKfPexl+P+VdQtKZeIT87iyrCk/OAGPnnyPZYRWWZSZM8KwyC12Crat7JXnC rEAK7P/X2lOuSe2FR6Dg8e+Mvz4KX6Ryj5Y4/qGkdDkdnwRCjOOh/fl/UBwGj6ImTo+S bF0SVZ/B2mLmAYwJk2v9mqyr7B9sQpfrThn0Bm1/bs/kPZAE38TPAqYp82XxEI+ZSldm RF7w4T0yLoQb00aO4QVUyEOl6R4Euheb7IcQ0I7m9/2AfiFE/Og4zObD5WDHf4vcLWU8 1a8g== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr2758882wjb.21.1382624074958; Thu, 24 Oct 2013 07:14:34 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Thu, 24 Oct 2013 07:14:34 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0BE94D@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B0BE94D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 24 Oct 2013 09:14:34 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e011779b5d88e8804e97d4023 Subject: [clue] Fwd: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:14:39 -0000 --089e011779b5d88e8804e97d4023 Content-Type: text/plain; charset=ISO-8859-1 CLUE folks should also review this document and provide your comments on the AVTEXT mailing list. Mary. ---------- Forwarded message ---------- From: DRAGE, Keith (Keith) Date: Thu, Oct 24, 2013 at 8:23 AM Subject: [avtext] draft-lennox-raiarea-rtp-grouping-taxonomy To: "avtext@ietf.org" (As WG co-chair) The following draft: https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxonomy/ draft-lennox-raiarea-rtp-grouping-taxonomy-03 A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources Has been significantly updated. We already have the milestone for this work. I'd like to start a call to adopt this text as a WG item. So please respond to this mail with either support, not support, or support only part of the text (if the latter please be specific as to which parts cause issues). Please respond by Tuesday 5th November. We will also do a final call at the face to face meeting, but please raise issues before this. Please also feel free to raise separately any issues you would like fixed in the text which you believe do not impact the call above. Also any subject matter that you think is missing. It would be good to know that some people have read the draft. Regards Keith _______________________________________________ avtext mailing list avtext@ietf.org https://www.ietf.org/mailman/listinfo/avtext --089e011779b5d88e8804e97d4023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      CLUE folks should also review this document and provide yo= ur comments on the AVTEXT mailing list.=A0

      Mary.

      =
      ---------- Forwarded message ----------
      From:= DRAGE, Keith (Keith) &= lt;keith.drage@alcatel-lu= cent.com>
      Date: Thu, Oct 24, 2013 at 8:23 AM
      Subject: [avtext] draft-lennox-raiare= a-rtp-grouping-taxonomy
      To: "avt= ext@ietf.org" <avtext@ietf.o= rg>


      (As WG co-chair)

      The following draft:

      https://datatracker.ietf.org/doc/draft-lenn= ox-raiarea-rtp-grouping-taxonomy/
      draft-lennox-raiarea-rtp-grouping-taxonomy-03
      A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Pro= tocol (RTP) Sources

      Has been significantly updated.

      We already have the milestone for this work.

      I'd like to start a call to adopt this text as a WG item. So please res= pond to this mail with either support, not support, or support only part of= the text (if the latter please be specific as to which parts cause issues)= .

      Please respond by Tuesday 5th November. We will also do a final call at the= face to face meeting, but please raise issues before this.

      Please also feel free to raise separately any issues you would like fixed i= n the text which you believe do not impact the call above. Also any subject= matter that you think is missing. It would be good to know that some peopl= e have read the draft.

      Regards

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

      --089e011779b5d88e8804e97d4023-- From mary.ietf.barnes@gmail.com Thu Oct 24 09:06:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15111E8398 for ; Thu, 24 Oct 2013 09:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLUCsi5hcX0j for ; Thu, 24 Oct 2013 09:06:18 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0611E82DA for ; Thu, 24 Oct 2013 08:59:07 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so2499263wgh.1 for ; Thu, 24 Oct 2013 08:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iT71A7+rP/h4Z23Gm4CovpOZcExGt5CL7xX63HE79XI=; b=I7Eoo4PDfZyRTogQjYxPE/+k48XFpstcBOjx0SXKlTs05TtmiURAzhRRqoyMLKfjRV LCCV9xCsujgJPU85mcngxvs119cRc/qWFQMgUI4KHeEobZOlyzE7W5zXNOeCBpAahHof MaiI68Lw1TwApGVHUJ0QjO7UKeHwZYAevzEVoCSkCIblQ9aBbF09EsGJFmsBeQeupJqQ 1EHRES1Qr1UVpjTG/nn4YtDopuX0YepsCaERCctnoxFkugRduUDVbilnMXXOThbbCWNd ciBKSdtGeYqtLTkDItkjJjKP15tWLWAPP2ZN5+fVV/Lb7ETwSsyjDBSg/l/JulSZMs1P UwZw== MIME-Version: 1.0 X-Received: by 10.194.118.169 with SMTP id kn9mr2505451wjb.71.1382630334188; Thu, 24 Oct 2013 08:58:54 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Thu, 24 Oct 2013 08:58:54 -0700 (PDT) Date: Thu, 24 Oct 2013 10:58:54 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01176463ecd28a04e97eb50e Subject: [clue] Updating CLUE WG milestones X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:06:19 -0000 --089e01176463ecd28a04e97eb50e Content-Type: text/plain; charset=ISO-8859-1 We've had an action item for a while to update the CLUE WG milestones. I've put in requests to have the milestones updated as follows - adding milestones for more discrete deliverables that we believe correspond to individual documents: Nov 2013 Submit informational draft to IESG on requirements Aug 2014 Submit standards track draft to IESG on Framework Aug 2014 Submit standards track draft to IESG on Data Model Sept 2014 Submit standards track draft to IESG on CLUE Protocol Sept 2014 Submit standards track draft to IESG on CLUE Data Channel Oct 2014 Submit standards track draft to IESG on Usage of RTP Nov 2014 Submit standards track draft to IESG on Overall Signaling and usage of SDP Dec 2014 Submit informational draft to IESG on Call Flows These have not yet been approved by the AD and thus are not yet visible on the WG charter page. We also have a spreadsheet with some intermediate dates (e.g., pre-WGLC, WGLC) along with primary editors and the chair that will shepherd the work. I've uploaded the spreadsheet to the wiki for your reference: http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart (CLUE Project Plan link). You'll see for example, that we are planning a WGLC of the framework and data model a good bit earlier than the date to send to the IESG. As we discussed the plan is to hold onto documents until the related solution work is more mature. We are doing the publication requests in sets sequentially rather than all at once as it will be easier for everyone to be focusing on just a couple documents at each stage. We will also be requesting early reviews of the directorates. This should make the completion of the docs go more smoothly as external folks will see the documents at WLGC for the first time as opposed to IETF LC. Regards, Mary and Paul --089e01176463ecd28a04e97eb50e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      We've had an action item for a while to update the CLU= E WG milestones. =A0I've put in requests to have the milestones updated= as follows - adding milestones for more discrete deliverables that we beli= eve correspond to individual documents:=A0

      <= div>Nov 2013 =A0 Submit informational draft to IESG on requirements
      Aug 2014 =A0 Submit standards track draft to IESG on Framework
      Aug 2014 =A0 Submit standards track d= raft to IESG on Data Model
      Sep= t 2014 =A0Submit standards track draft to IESG on CLUE Protocol
      Sept 201= 4 =A0Submit standards track draft to IESG on CLUE Data Channel
      Oct 2014 =A0 =A0Submit standards track draft to IESG on Usage of RTP
      Nov= 2014 =A0 Submit standards track draft to IESG on Overall Signaling
      =A0 = =A0 and usage of SDP
      Dec 2014 =A0 Submit informational draft to IESG on = Call Flows

      These have not yet been approved by the AD = and thus are not yet visible on the WG charter page.=A0
      =
      We also have a spreadsheet with some intermediate dates (e.g= ., pre-WGLC, WGLC) along with primary editors and the chair that will sheph= erd the work. =A0I've uploaded the spreadsheet to the wiki for your ref= erence:=A0http://trac.tools.ietf.org/wg/clue/trac/wiki/WikiStart =A0(CLUE Proje= ct Plan link).=A0

      You'll see for example, that we are planning = a WGLC of the framework and data model a good bit earlier than the date to = send to the IESG. =A0As we discussed the plan is to hold onto documents unt= il the related solution work is more mature. =A0We are doing the publicatio= n requests in sets sequentially rather than all at once as it will be easie= r for everyone to be focusing on just a couple documents at each stage. We = will also be requesting early reviews of the directorates. This should make= the completion of the docs go more smoothly as external folks will see the= documents at WLGC for the first time as opposed to IETF LC.

      Regards,
      Mary and Paul

      --089e01176463ecd28a04e97eb50e-- From mary.ietf.barnes@gmail.com Thu Oct 24 10:28:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB311E835C for ; Thu, 24 Oct 2013 10:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h09hwBszBBmc for ; Thu, 24 Oct 2013 10:28:04 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id F0FBF11E81B4 for ; Thu, 24 Oct 2013 10:28:03 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id b13so2680774wgh.27 for ; Thu, 24 Oct 2013 10:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=W00nhEROGO9oIIZQ8/dL2XqDwXFWhaHRTAYVoGb5fIk=; b=ipI/rT6ZZ/1LgND07ClpOV3ftCOBbvghJSGseaQh9jcImE1rbHyaVaqvxYkz8J0bdY 710x9K1NzwsY16eQ3hKMCCfAPetZptvEpRJqjfnBLFHws3G7tvtbtOi1G+8ArLo1K1UC FBtq3kjb3PJY3TgbEL6dFVRffbdq1HTjdX64vIzuFtUxGkv17R1gDrQCbBTmvQf4Fqxc DNIblujl1EUvitxip1tct12iAuSyzfPAL2xnWLYQpdbb9aQjewIipg2K9pRE4h7T6Tyr Nhl2mqVK/Er0gu+rHV34AO6En258O8MQcZL/zGK9fNL7/n+lK7Q8Ehoy16gRrGnN1OTr thMg== MIME-Version: 1.0 X-Received: by 10.180.89.42 with SMTP id bl10mr3100521wib.47.1382635683077; Thu, 24 Oct 2013 10:28:03 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Thu, 24 Oct 2013 10:28:03 -0700 (PDT) Date: Thu, 24 Oct 2013 12:28:03 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04447e2fbe67c404e97ff416 Subject: [clue] Updated CLUE WG agenda for IETF-88 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:28:04 -0000 --f46d04447e2fbe67c404e97ff416 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We've made some minor changes to the original agenda: https://datatracker.ietf.org/meeting/88/agenda/clue/ Note, you may need to refresh your browser to se the revised version if you'd previously looked at the agenda. Please provide any feedback and raise any concerns ASAP. The Friday agenda is quite open at this time and we'll update it with details based upon how discussions go on Tuesday to allow continuation of discussions if we run out of time or to focus on key issues that we didn't resolve. The chairs would like to request that slides be sent no later than noon on Sunday, Nov 3rd so that we have time to upload and so they'll be available to remote participants before the session. Thanks, Mary and Paul --f46d04447e2fbe67c404e97ff416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      Hi all,

      We've made some minor chang= es to the original agenda:=A0

      Note, you may need to refresh your browser = to se the revised version if you'd previously looked at the agenda. =A0= Please provide any feedback and raise any concerns ASAP. =A0The Friday age= nda is quite open at this time and we'll update it with details based u= pon how discussions go on Tuesday to allow continuation of discussions if w= e run out of time or to focus on key issues that we didn't resolve. =A0=

      The chairs would like to request that slide= s be sent no later than noon on Sunday, Nov 3rd so that we have time to upl= oad and so they'll be available to remote participants before the sessi= on.=A0

      Thanks,
      Mary and Paul
      =
      --f46d04447e2fbe67c404e97ff416-- From ietf-secretariat-reply@ietf.org Thu Oct 24 11:23:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A4011E835C for ; Thu, 24 Oct 2013 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyht+NEUQn3b for ; Thu, 24 Oct 2013 11:23:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEC411E837C for ; Thu, 24 Oct 2013 11:23:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131024182340.19014.94695.idtracker@ietfa.amsl.com> Date: Thu, 24 Oct 2013 11:23:40 -0700 From: IETF Secretariat X-Mailman-Approved-At: Thu, 24 Oct 2013 11:52:47 -0700 Subject: [clue] Milestones changed for clue WG X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:23:43 -0000 Changed milestone "Submit informational draft to IESG on framework and requirements", set description to "Submit informational draft to IESG on requirements". Changed milestone "Submit standards track specification(s) to IESG to support framework and requirements", set description to "Submit standards track draft to IESG on Framework". Changed milestone "Submit standards track draft to IESG on Data Model", set state to active from review, accepting new milestone. Changed milestone "Submit standards track draft to IESG on CLUE Protocol", set state to active from review, accepting new milestone. Changed milestone "Submit standards track draft to IESG on CLUE Data Channel", set state to active from review, accepting new milestone. Changed milestone "Submit standards track draft to IESG on Usage of RTP", set state to active from review, accepting new milestone. Changed milestone "Submit standards track draft to IESG on Overall Signaling and usage of SDP", set state to active from review, accepting new milestone. Changed milestone "Submit informational draft to IESG on Call Flows", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/clue/charter/ From coverdale@sympatico.ca Thu Oct 24 12:09:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D621E8092 for ; Thu, 24 Oct 2013 12:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7dGdpbGsLjb for ; Thu, 24 Oct 2013 12:09:26 -0700 (PDT) Received: from blu0-omc1-s29.blu0.hotmail.com (blu0-omc1-s29.blu0.hotmail.com [65.55.116.40]) by ietfa.amsl.com (Postfix) with ESMTP id E5EA221E8091 for ; Thu, 24 Oct 2013 12:09:25 -0700 (PDT) Received: from BLU0-SMTP70 ([65.55.116.9]) by blu0-omc1-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 12:09:25 -0700 X-TMN: [VEtcz/F7ioWLjIZnlmjxgJbDyJJVIsTM] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([74.15.61.23]) by BLU0-SMTP70.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Oct 2013 12:09:22 -0700 From: Paul Coverdale To: "'Paul Kyzivat'" , References: <52403F44.2060609@unina.it> <52563818.8040402@nteczone.com> <52573B92.4050801@nteczone.com> <525DDC15.1040807@nteczone.com> <525F4D0B.8090900@nteczone.com> <526847DC.6060209@alum.mit.edu> In-Reply-To: <526847DC.6060209@alum.mit.edu> Date: Thu, 24 Oct 2013 15:09:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7QO97NjLn9LyHVTam2nWhV7azRkAAro0Aw Content-Language: en-us X-OriginalArrivalTime: 24 Oct 2013 19:09:23.0061 (UTC) FILETIME=[8CA20250:01CED0EC] Subject: Re: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:09:32 -0000 I don't want to open a discussion on the definition of architecture in general, but in the context of CLUE my view is that "architecture" should define all the entities that are required to make the protocol work, and interoperate with other protocols where necessary, but shouldn't define a telepresence system itself. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Paul Kyzivat >Sent: Wednesday, October 23, 2013 6:04 PM >To: clue@ietf.org >Subject: Re: [clue] comments to draft-ietf-clue-telepresence- >requirements-05.txt > >Interesting discussion about what architecture is/isn't. > >Ultimately we are describing an actual protocol, and profiling some use >of other protocols. That protocol references an assortment of entities, >for instance scenes, capture devices, and sites. (We haven't formally >defined sites, but we keep talking about them, so we ought to define.) >ISTM that the high level description of those things and their >relationships is an architecture for the kinds of telepresence systems >we are addressing. Is that a "protocol architecture"? Or is it an >architecture for the systems that the protocol is intended to support? > > Thanks, > Paul > >On 10/17/13 11:42 AM, Paul Coverdale wrote: >> OK, thanks for the clarification, Christian. I agree with your concern >> and I support your new proposed text, with a slight change to correct >> the English (addition of a semi-colon and the word "how"). >> >> So the new text reads: >> >> "CLUE will not dictate an overall Telepresence system architecture and >> implementation choices; however it will describe a protocol >> architecture for CLUE and how it relates to other protocols." >> >> >> ...Paul >> >> >> From pkyzivat@alum.mit.edu Sun Oct 27 09:47:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4211E828F for ; Sun, 27 Oct 2013 09:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chPE9o1Tft-m for ; Sun, 27 Oct 2013 09:47:24 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id D37B711E8259 for ; Sun, 27 Oct 2013 09:47:21 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id iGHU1m0061vXlb851GnLGz; Sun, 27 Oct 2013 16:47:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id iGnL1m00P3ZTu2S3dGnLaA; Sun, 27 Oct 2013 16:47:20 +0000 Message-ID: <526D4398.6030701@alum.mit.edu> Date: Sun, 27 Oct 2013 12:47:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1382892440; bh=MfRv8ynuFnTTPbm2BR5sRjI3Z7CSguYtRltRwnUmI2U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H0vBkkHamu/cMGGfShVmj5xsW+A2g6S6nPOQTQen44Al75aJyScFvSbvntTfT0IoI u9xM4l+t85MiM/YY7FkajsmwXR3UKxnr87niS45svrTb7boO44WMOrXBh/cZrVsJwN Nr+PulBaEeenhSLlaRQBoz/pd+o2MfDdNgihfuSwGW0VKhnrbcXfLsA0p+Kh/gyeOl 4NOzMWZvUoA3roQN+LWgiH2G3rvwABxL+tkk+r/LJ+N1sDHJVmUpsociAYflM/eVZR 5/mG8XJo52YRFTCx+vXG8ztYfdBq3Z3z/UZ2xViEdc36VkbypQMANQzMi2fle5mjen xxeYSz8tlbzHQ== Subject: [clue] comments on draft-ietf-clue-framework-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 16:47:30 -0000 While preparing for the meeting I reviewed the framework document again. I have a number of comments. These are all quite detail-oriented, rather than conceptual. I see no reason to discuss these at the meeting - it should be possible to deal with them all via email. General observation: This version introduced a lot of new normative language. While some of it seems appropriate, some is not. Normative language should only be used for things that are actionable. I'll call out the specific points where I see this below. Section 5 says: This CLUE exchange MUST be followed by an SDP offer answer exchange that not only establishes those aspects of the media that have not been "negotiated" over CLUE, but has also the side effect of setting up the media transmission itself, involving potentially security exchanges, ICE, and whatnot. I think this is a bit too strong. While it is *likely* that another O/A exchange will be needed, I don't think it is mandatory. If it turns out that the SDP already in effect is sufficient, then no new O/A is needed. A degenerate case of this is when nothing is configured. I suggest replacing "MUST be" by "will usually be" Later in the section: For example, voice-activated screen switching, signaled over the CLUE channel, ought not to lead to heavy-handed mechanisms like SIP re-invites. However, in other cases, after the CLUE negotiation an additional offer/answer exchange becomes necessary. For example, if both sides decide to upgrade the call from a single screen to a multi-screen call and more bandwidth is required for the additional video channels compared to what was previously negotiated using offer/answer, a new O/A exchange is REQUIRED. This seems fine except that the normative language is inappropriate. There is nothing normative here. The new O/A exchange is triggered by circumstances, not rules. So I suggest simply reverting the change from -11 to -12 that introduced "REQUIRED". Later in the section: The operation of the renderer inside the Consumer is unspecified in that it can choose to ignore some information provided by the Provider, and/or not render media streams available from the Provider (although it MUST follow the CLUE protocol and, therefore, MUST gracefully receive and respond (through a Configure) to the Provider's information). All CLUE protocol mechanisms are OPTIONAL in the Consumer in the sense that, while the Consumer MUST be able to receive (and, potentially, gracefully acknowledge) CLUE messages, it is free to ignore the information provided therein. Obviously, this is not a particularly sensible design choice in almost all conceivable cases. IIUC it's still not settled whether a Configure MUST be sent in response to an Advertisement. So "(although it MUST ..." is suspect. It can be left for now, but may need to be updated later. Or we could just remove it now. I also question the use of OPTIONAL in the normative sense. If something is to be said about that, it might be something about "mandatory to implement, optional to use". Still later: A CLUE-implementing device interoperates with a device that does not support CLUE, because the non-CLUE device does, by definition, not understand the offer of a CLUE channel in the initial offer/answer exchange and, therefore, will reject it. This rejection MUST be used as the indication to the CLUE-implementing device that the other side of the communication is not compliant with CLUE, and to fall back to behavior that does not require CLUE. Again, the MUST seems inappropriate. It is not something that needs to be dictated. The CLUE device has no option to follow CLUE in this case. Section 6: o Coordinates can either be in real, physical units (millimeters), have an unknown scale or have no physical scale. Systems which know their physical dimensions (for example professionally installed Telepresence room systems) MUST always provide those real-world measurements. Systems which don't know specific physical dimensions but still know relative distances MUST use 'unknown scale'. I question "MUST" here. What bad things happen if the MUSTs are violated. Why not "SHOULD"? I guess it comes down to what it means for for a system to "know" something. I guess it would be possible for a system to "know" this but wish to hide that knowledge. ISTM what is key is that there are benefits to providing this information, and negative consequences (to interoperability) from not providing it. So one SHOULD provide this information unless the desire to hide it is more important than the potential value of providing it. Section 7.3: If an Advertisement does not include Simultaneous Transmission Sets, then the Provider MUST be able to provide all Capture Scenes simultaneously. If multiple capture Scene Entries are in a Capture Scene then the Consumer chooses at most one Capture Scene Entry per Capture Scene for each media type. I'm not sure what this is trying to say. If I read the first sentence in the context with the prior paragraph I conclude that there is a default simultaneous set that lists all the scenes in the advertisement. But when I read the 2nd sentence, then I conclude that something weaker is being implied - that by default simultaneity is required between any arbitrary choice of a single CSE from each scene. If the latter is intended, then I think the point needs to be made more clearly. Perhaps the algorithm for defining the default simultaneous sets could be specified. Section 10: For each Capture the Consumer wants to receive, it configures one or more of the encodings in that capture's encoding group. The Consumer does this by telling the Provider, in its Configure Message, parameters such as the resolution, frame rate, bandwidth, etc. for each Capture Encodings for its chosen Captures. Upon receipt of this Configure from the Consumer, common knowledge is established between Provider and Consumer regarding sensible choices for the media streams and their parameters. The setup of the actual media channels, at least in the simplest case, is left to a following offer-answer exchange. Optimized implementations MAY speed up the reaction to the offer-answer exchange by reserving the resources at the time of finalization of the CLUE handshake. I don't think this is accurate when Encodings are represented in SDP. I won't attempt to wordsmith a revision here - it may require a substantial rewrite. Thanks, Paul (as individual) From Mark.Duckworth@polycom.com Mon Oct 28 15:57:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FDE11E8152 for ; Mon, 28 Oct 2013 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUqOzl+A5u1D for ; Mon, 28 Oct 2013 15:57:30 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4E03611E810B for ; Mon, 28 Oct 2013 15:57:30 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 28 Oct 2013 15:57:29 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 28 Oct 2013 15:57:27 -0700 Thread-Topic: [clue] Example of MCC - consumer driven layout and switching Thread-Index: Ac7QFYtPVtKvuE7ET3GMrfSIBsvTRAEGfttA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D603D977DA@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> <52661954.2010202@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D603A7C3B9@CRPMBOXPRD07.polycom.com> <5268079C.6090106@alum.mit.edu> In-Reply-To: <5268079C.6090106@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:57:37 -0000 Hi Paul, Yes, you understand correctly. Yes, it requires the consumer to know (or be= able to figure out) which video streams are associated with the active spe= aker. I think this is needed anyway, for other things (lip sync, spatial r= endering, UI indications). I think it is realistic to do it this way. I in= tend to discuss more with my colleagues, who have more experience in this a= spect of media switching. Are you concerned about the frequency of these decisions being a problem? O= r about the latency for each individual decision? I think latency is more l= ikely to be a problem. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, October 23, 2013 1:30 PM > To: clue@ietf.org > Subject: Re: [clue] Example of MCC - consumer driven layout and switching >=20 > Mark, >=20 > IIUC you are suggesting that the consumer might be making decisions and > sending configure messages about the captures it wants to receive every > time the active speaker changes. >=20 > And it requires that the active speaker mapping to source capture id be > available to the consumer >=20 > Isn't it unrealistic to think that this could work well at that time scal= e? >=20 > Thanks, > Paul >=20 > On 10/22/13 6:13 AM, Duckworth, Mark wrote: > > Hi Christian, > > > > I understand the scenario you are talking about, where the MCU chooses > the MC for the MCC based on some policy. But I think it leads to some > potential problems. Like we said below, the MCU has to anticipate the > rendering desires of the receiving endpoint, at least to some extent. An= d > also the receiving endpoint might have to remap a video decoder to a > different rendering location every time the MCU makes a switch. This see= ms > like a problem for an endpoint that has particular decoders hardwired to > different displays. I think these problems can be resolved if the receiv= er > makes more explicit choices about what it wants to receive in each MCC. > > > > Yes, I was thinking of something like a subscribe/notify mechanism for = a > "recent talker list". I'm not sure it's really needed though, maybe inst= ead the > receiver can get this information from the audio streams, if the MCU send= s > something like the N most active audio streams. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Christian Groves > >> Sent: Tuesday, October 22, 2013 2:21 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] Example of MCC - consumer driven layout and > >> switching > >> > >> Hello Mark, > >> > >> I guess I saw this slightly differently. Rather than chose the MC > >> based on voice activity I saw that a consumer would chose the MC in > >> the MCC based on the sources it wanted. It would then choose an > >> applicable policy (i.e. most active, two most active, etc). The MCU > >> would provide the appropriate MC based on this policy. > >> > >> For the "most recent talker list" it sounds like a subscribe/notify > >> mechanism where the Consumer would subscribe to events and then be > >> notified of it. Is this the sort of thing that you were thinking of? > >> > >> Regards, Christian > >> > >> On 12/10/2013 2:57 AM, Duckworth, Mark wrote: > >>> I'm branching this topic off the MCC discussion, keeping just a > >>> small section > >> of previous email. > >>> > >>> I have another suggestion to consider about making media switching > >> decisions - see below. Has anybody else considered an idea like this? > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Robert Hansen > >>>> Sent: Monday, September 30, 2013 12:43 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] Example of MCC > >>>> > >>>>> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: > >>>>>> One downside to this approach is that every change the MCU makes > >>>>>> in how it assigns contributing VCs to an MCC (e.g. make a switch > >>>>>> based on current talker) could result in the consumer renderer > >>>>>> needing to change how it maps decoder output to display > >>>>>> locations. I need to think more about if this would really be a > problem or not. > >>>> [RH] My issue with using the spatial coordinates of the MCC is that > >>>> it requires the MCU to anticipate the rendering desires of the > >>>> endpoint, as the MCU will need to advertise MCCs with spatial > >>>> coordinates that allow the endpoint to do what it wants to do. My > >>>> concern has always been that this may lead to huge numbers of MCCs > >>>> and capture scene entries if the MCU is trying to anticipate > >>>> potential > >> layouts by the endpoint. > >>> I agree it is good if the MCU does not have to anticipate the > >>> rendering > >> (layout) desires of the endpoint consumer. So I consider if it is > >> better if the consumer can make even more of the decisions, including > >> dynamically selecting which source capture should be included in an > >> MCC. draft-groves- > >> clue-multi-content-00 says "The Consumer may or may not want to > >> receive all the indicated captures. Therefore it can choose to > >> receive a sub-set of captures indicated by the MCC." This means the > >> consumer can choose, in a configure message, to receive the one > >> particular capture it wants at that moment, for each MCC. And it can > >> send new configure messages any time, to change this choice. I think = this > would not require any SDP exchanges. > >>> > >>> If the consumer makes these choices (which still must be consistent > >>> with > >> the advertisement), then the provider doesn't have to make any > >> switching choices any more. The consumer can make its choices based > >> on its own local policy for layout and rendering. > >>> > >>> But the consumer would need some more information about current > >> activity in the conference in order to make these decisions. The > >> consumer would need to know about audio activity, for example in the > >> form of a "most recent talker list" or something like that, in order > >> to make the decisions about which MC it wants to receive within each > >> MCC. I don't know of any existing standard way to convey that > >> information. It seems to me a provider could send a "most recent > >> talker list" to a consumer via the CLUE channel. Is anybody intereste= d in > pursuing this idea? > >>> > >>> Mark > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From iesg-secretary@ietf.org Wed Oct 30 06:17:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE19521F9F4F; Wed, 30 Oct 2013 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqLD7CH6QQ82; Wed, 30 Oct 2013 06:17:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A3F11E8171; Wed, 30 Oct 2013 06:17:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131030131708.6969.31144.idtracker@ietfa.amsl.com> Date: Wed, 30 Oct 2013 06:17:08 -0700 Cc: clue@ietf.org Subject: [clue] Last Call: (Requirements for Telepresence Multi-Streams) to Informational RFC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:17:14 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'Requirements for Telepresence Multi-Streams' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and related definitions are also covered herein. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From pkyzivat@alum.mit.edu Wed Oct 30 06:42:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8021F9E36 for ; Wed, 30 Oct 2013 06:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW1FZKODJoZy for ; Wed, 30 Oct 2013 06:42:49 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 690C311E8220 for ; Wed, 30 Oct 2013 06:42:37 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id jRbT1m00D0cZkys53RibRj; Wed, 30 Oct 2013 13:42:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id jRia1m0113ZTu2S3WRibJ9; Wed, 30 Oct 2013 13:42:35 +0000 Message-ID: <52710CCA.7010006@alum.mit.edu> Date: Wed, 30 Oct 2013 09:42:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <49E45C59CA48264997FEBFB29B6BC2D60379FFC8@CRPMBOXPRD07.polycom.com> <52661954.2010202@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D603A7C3B9@CRPMBOXPRD07.polycom.com> <5268079C.6090106@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D603D977DA@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D603D977DA@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383140555; bh=fOFyPYi40Ipfkzggexzy58XvA3T3a6KbTbg1BfgORp4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tm1N6E44XmgJVDS0oc0/rqK8oR+ejkieJE4E+/rw+RsE3BHAXA1BnR6gqwAZF18Bb 7gJQ2KuE7jPEr+YFDd1yRuRsKam3qC49KeqUvGkroLgErkL7QGjse9NPUag7ygu0Hm NDhoi9U8qL6e8kVAayZIORzPBYXZ8suSyqmoWYbTOEZHrWmpJLY2AH36lMmqBVg0MB QG4WnhvsFor+TG35Ex7wvH+ArSS6Jt8EON91TPi3HXA0v5+3vce8IqOVp6Gqglpn77 lNMqTfaNlBNrkSoSSTzWeMys58T5bbfwZj9DmV9CxN8D501DV2ANuCesdvPkxyhn82 mpC6sL50s1arA== Subject: Re: [clue] Example of MCC - consumer driven layout and switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 13:42:53 -0000 On 10/28/13 6:57 PM, Duckworth, Mark wrote: > Hi Paul, > > Yes, you understand correctly. Yes, it requires the consumer to know (or be able to figure out) which video streams are associated with the active speaker. OK. > I think this is needed anyway, for other things (lip sync, spatial rendering, UI indications). I think it is realistic to do it this way. Then I think we do need to say more about *how* this is done. I suppose the mechanisms for lip sync could be used to correlate audio and video to some extent. But I don't think that is enough to figure out which display holds loudest speaker. Maybe spatial info could help. But we have had input that the spatial info for audio has a much different meaning than spatial info for video, so correlating them could be difficult. > I intend to discuss more with my colleagues, who have more experience in this aspect of media switching. And maybe others here can speak to that too. > Are you concerned about the frequency of these decisions being a problem? Or about the latency for each individual decision? I think latency is more likely to be a problem. Both. But it is only "concern". I don't have enough knowledge to decide if my concern is justified. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Wednesday, October 23, 2013 1:30 PM >> To: clue@ietf.org >> Subject: Re: [clue] Example of MCC - consumer driven layout and switching >> >> Mark, >> >> IIUC you are suggesting that the consumer might be making decisions and >> sending configure messages about the captures it wants to receive every >> time the active speaker changes. >> >> And it requires that the active speaker mapping to source capture id be >> available to the consumer >> >> Isn't it unrealistic to think that this could work well at that time scale? >> >> Thanks, >> Paul >> >> On 10/22/13 6:13 AM, Duckworth, Mark wrote: >>> Hi Christian, >>> >>> I understand the scenario you are talking about, where the MCU chooses >> the MC for the MCC based on some policy. But I think it leads to some >> potential problems. Like we said below, the MCU has to anticipate the >> rendering desires of the receiving endpoint, at least to some extent. And >> also the receiving endpoint might have to remap a video decoder to a >> different rendering location every time the MCU makes a switch. This seems >> like a problem for an endpoint that has particular decoders hardwired to >> different displays. I think these problems can be resolved if the receiver >> makes more explicit choices about what it wants to receive in each MCC. >>> >>> Yes, I was thinking of something like a subscribe/notify mechanism for a >> "recent talker list". I'm not sure it's really needed though, maybe instead the >> receiver can get this information from the audio streams, if the MCU sends >> something like the N most active audio streams. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Christian Groves >>>> Sent: Tuesday, October 22, 2013 2:21 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Example of MCC - consumer driven layout and >>>> switching >>>> >>>> Hello Mark, >>>> >>>> I guess I saw this slightly differently. Rather than chose the MC >>>> based on voice activity I saw that a consumer would chose the MC in >>>> the MCC based on the sources it wanted. It would then choose an >>>> applicable policy (i.e. most active, two most active, etc). The MCU >>>> would provide the appropriate MC based on this policy. >>>> >>>> For the "most recent talker list" it sounds like a subscribe/notify >>>> mechanism where the Consumer would subscribe to events and then be >>>> notified of it. Is this the sort of thing that you were thinking of? >>>> >>>> Regards, Christian >>>> >>>> On 12/10/2013 2:57 AM, Duckworth, Mark wrote: >>>>> I'm branching this topic off the MCC discussion, keeping just a >>>>> small section >>>> of previous email. >>>>> >>>>> I have another suggestion to consider about making media switching >>>> decisions - see below. Has anybody else considered an idea like this? >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Robert Hansen >>>>>> Sent: Monday, September 30, 2013 12:43 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Example of MCC >>>>>> >>>>>>> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: >>>>>>>> One downside to this approach is that every change the MCU makes >>>>>>>> in how it assigns contributing VCs to an MCC (e.g. make a switch >>>>>>>> based on current talker) could result in the consumer renderer >>>>>>>> needing to change how it maps decoder output to display >>>>>>>> locations. I need to think more about if this would really be a >> problem or not. >>>>>> [RH] My issue with using the spatial coordinates of the MCC is that >>>>>> it requires the MCU to anticipate the rendering desires of the >>>>>> endpoint, as the MCU will need to advertise MCCs with spatial >>>>>> coordinates that allow the endpoint to do what it wants to do. My >>>>>> concern has always been that this may lead to huge numbers of MCCs >>>>>> and capture scene entries if the MCU is trying to anticipate >>>>>> potential >>>> layouts by the endpoint. >>>>> I agree it is good if the MCU does not have to anticipate the >>>>> rendering >>>> (layout) desires of the endpoint consumer. So I consider if it is >>>> better if the consumer can make even more of the decisions, including >>>> dynamically selecting which source capture should be included in an >>>> MCC. draft-groves- >>>> clue-multi-content-00 says "The Consumer may or may not want to >>>> receive all the indicated captures. Therefore it can choose to >>>> receive a sub-set of captures indicated by the MCC." This means the >>>> consumer can choose, in a configure message, to receive the one >>>> particular capture it wants at that moment, for each MCC. And it can >>>> send new configure messages any time, to change this choice. I think this >> would not require any SDP exchanges. >>>>> >>>>> If the consumer makes these choices (which still must be consistent >>>>> with >>>> the advertisement), then the provider doesn't have to make any >>>> switching choices any more. The consumer can make its choices based >>>> on its own local policy for layout and rendering. >>>>> >>>>> But the consumer would need some more information about current >>>> activity in the conference in order to make these decisions. The >>>> consumer would need to know about audio activity, for example in the >>>> form of a "most recent talker list" or something like that, in order >>>> to make the decisions about which MC it wants to receive within each >>>> MCC. I don't know of any existing standard way to convey that >>>> information. It seems to me a provider could send a "most recent >>>> talker list" to a consumer via the CLUE channel. Is anybody interested in >> pursuing this idea? >>>>> >>>>> Mark >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Oct 30 11:30:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8CC11E81A8 for ; Wed, 30 Oct 2013 11:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.25 X-Spam-Level: X-Spam-Status: No, score=-0.25 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7MACNxwKraL for ; Wed, 30 Oct 2013 11:30:43 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id BD3FA11E8182 for ; Wed, 30 Oct 2013 11:30:39 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id jRqM1m0090mv7h05FWWf0k; Wed, 30 Oct 2013 18:30:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id jWWf1m0093ZTu2S3XWWf7R; Wed, 30 Oct 2013 18:30:39 +0000 Message-ID: <5271504F.7050702@alum.mit.edu> Date: Wed, 30 Oct 2013 14:30:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1383157839; bh=sYgoGSJ5MPcXtc/+0biYHgPNSu8w/380e6PPb3/zpLA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hp6z6egJVJVvHssFCa0yMWSMVe94uvCYn22GeY8tjNegApbP/aYbsqiDCldB+QUPO v20H3nfM4r5ZpdU+n+ck3rtmYCJAhpfgkQ7gI2lTOXs5TonVcD3bJ/nJpesU2vsoXg OtzQncuWui3mpFw8mgP9I0lktNrML+ds5SnzUSxyorV6aULCxTGGh/gPKMo2Ty2gmz 9+8Eu0JATGAsYXb34ekVuLrEis6+naEWKSa89NajXfSAXN2AdRSWT6d4Clyi6IxVR8 /96gxsx1POsh4Y8/JpQvknWByl4EAAyB/7tAm0HRnghkDJcFqHWkkogXYYf7LduRBh 3iIZKjMbwx5sA== Subject: [clue] small comment on data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 18:30:48 -0000 I was discussing with coworkers how media type is represented in the data model, and realized that it isn't entirely clear and explicit about this. Specifically: 10. ... ... 10.1. is a mandatory field specifying the media type of the capture ("audio", "video", "text",...). This is fine, but the actual type of the element is an unrestricted string, and the only guidance about what goes into it are the examples. When I look at the examples, I immediately infer that what is intended to go here is a value suitable for use as the field of an m-line in SDP. But not everyone will leap to that conclusion. ISTM that we should normatively specify that. E.g., 10.1. is a mandatory field specifying the media type of the capture. The value MUST be one of those registered in the "media" sub-table of the IANA "Session Description Protocol (SDP) Parameters" registry. (http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-1). For example, "audio" or "video". Thanks, Paul From trac+clue@trac.tools.ietf.org Thu Oct 31 07:17:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738C311E8149 for ; Thu, 31 Oct 2013 07:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCWrMShK7AFK for ; Thu, 31 Oct 2013 07:17:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C61D411E81C6 for ; Thu, 31 Oct 2013 07:17:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:46868 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbt3k-0005vd-QC; Thu, 31 Oct 2013 15:17:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:17:16 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/36#comment:1 Message-ID: <083.ae792d6826188cbd6842fddb582b5175@trac.tools.ietf.org> References: <068.6a5d03d7c6b40be36d09dfcce1dc9d11@trac.tools.ietf.org> X-Trac-Ticket-ID: 36 In-Reply-To: <068.6a5d03d7c6b40be36d09dfcce1dc9d11@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #36: Cleanup encoding parameters for pixels/sec (computational complexity) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:17:22 -0000 #36: Cleanup encoding parameters for pixels/sec (computational complexity) Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was resolved in the -12 version of the framework. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 07:18:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D036C11E81C6 for ; Thu, 31 Oct 2013 07:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCWuUFkX2W9X for ; Thu, 31 Oct 2013 07:18:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EC76F11E8167 for ; Thu, 31 Oct 2013 07:18:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:46879 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbt4O-0002Lp-Ay; Thu, 31 Oct 2013 15:17:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:17:56 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/43#comment:1 Message-ID: <083.1aeb6defaae8c9304ad3e1f6d83ee78e@trac.tools.ietf.org> References: <068.78bc5564d1a103b791e047ecdd0d5221@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <068.78bc5564d1a103b791e047ecdd0d5221@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20131031141801.EC76F11E8167@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 07:18:01 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #43: Attributes with Consumer Choices X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:18:02 -0000 #43: Attributes with Consumer Choices Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was resolved in the -12 version of the framework. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 07:19:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA54621F8445 for ; Thu, 31 Oct 2013 07:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnaX6tJwKGQV for ; Thu, 31 Oct 2013 07:19:49 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B58C411E8149 for ; Thu, 31 Oct 2013 07:19:47 -0700 (PDT) Received: from localhost ([127.0.0.1]:47017 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbt69-0001NJ-Vs; Thu, 31 Oct 2013 15:19:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:19:45 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/44#comment:2 Message-ID: <083.54221cd30d81d6dccb44019f3ca04cf5@trac.tools.ietf.org> References: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031141947.B58C411E8149@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 07:19:47 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #44: Remove contradiction wrt responding to Advertisement with Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:19:50 -0000 #44: Remove contradiction wrt responding to Advertisement with Configure Changes (by mary.ietf.barnes@gmail.com): * owner: draft-ietf-clue-framework@tools.ietf.org => clue- chairs@tools.ietf.org * component: framework => charter Old description: > As discussed at IETF-87: > http://www.ietf.org/proceedings/87/minutes/minutes-87-clue > > And per the mailing list discussion: http://www.ietf.org/mail- > archive/web/clue/current/msg02684.html > > Action: Mark to post a proposal to mailing list to remove the details > from the framework. > > This should be changed to a Signaling/Solution document issue once we > have a WG document New description: As discussed at IETF-87: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue And per the mailing list discussion: http://www.ietf.org/mail- archive/web/clue/current/msg02684.html Action: Mark to post a proposal to mailing list to remove the details from the framework. The FW issue was resolved in the -12 version. This should be changed to a Signaling/Solution document issue once we have a WG document -- Comment: The framework issue was resolved in the -12 version of the framework. -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 07:58:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D845011E8125 for ; Thu, 31 Oct 2013 07:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTMnopii5pCr for ; Thu, 31 Oct 2013 07:58:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE021F9CF1 for ; Thu, 31 Oct 2013 07:58:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:50513 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbthL-0000XA-UH; Thu, 31 Oct 2013 15:58:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:58:11 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/12#comment:3 Message-ID: <083.b07a88ae7141e02cb65a748a38165861@trac.tools.ietf.org> References: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031145813.C1EE021F9CF1@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 07:58:13 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #12: Signaling: what data can be carried in SDP? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:58:15 -0000 #12: Signaling: what data can be carried in SDP? Description changed by mary.ietf.barnes@gmail.com: Old description: New description: Component = clue-signaling document -- -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 07:58:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE921F9DFC for ; Thu, 31 Oct 2013 07:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vyk42K0b-wsc for ; Thu, 31 Oct 2013 07:58:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AD0B821F9DF3 for ; Thu, 31 Oct 2013 07:58:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:50521 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbti1-0006Ry-9t; Thu, 31 Oct 2013 15:58:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:58:53 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/13#comment:1 Message-ID: <083.9265cd4cb14a947e0aa8eecc6bb7e1a4@trac.tools.ietf.org> References: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031145854.AD0B821F9DF3@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 07:58:54 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #13: Signaling: What data needs to be in CLUE specific signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:58:55 -0000 #13: Signaling: What data needs to be in CLUE specific signaling? Comment (by mary.ietf.barnes@gmail.com): Component= clue-protocol document -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 07:59:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C61021F9E3A for ; Thu, 31 Oct 2013 07:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP5xQ9wO6Dsd for ; Thu, 31 Oct 2013 07:59:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2277311E8167 for ; Thu, 31 Oct 2013 07:59:40 -0700 (PDT) Received: from localhost ([127.0.0.1]:50549 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbtik-0000Kx-H1; Thu, 31 Oct 2013 15:59:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 14:59:38 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/13#comment:2 Message-ID: <083.53d2e7593d21ecb0c07b48b77999b8ba@trac.tools.ietf.org> References: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031145940.2277311E8167@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 07:59:40 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #13: Signaling: What data needs to be in CLUE specific signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 14:59:44 -0000 #13: Signaling: What data needs to be in CLUE specific signaling? Description changed by mary.ietf.barnes@gmail.com: Old description: New description: Component = clue-protocol document -- -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:02:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43AD11E8222 for ; Thu, 31 Oct 2013 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz1v5MC3vB7b for ; Thu, 31 Oct 2013 08:02:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5B22C11E821E for ; Thu, 31 Oct 2013 08:01:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:50686 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbtkw-0000A9-NK; Thu, 31 Oct 2013 16:01:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:01:54 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/14#comment:2 Message-ID: <083.1df97b28e079899c9091fce6fb4fdce0@trac.tools.ietf.org> References: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031150158.5B22C11E821E@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 08:01:58 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #14: How do we transport the CLUE information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:02:02 -0000 #14: How do we transport the CLUE information? Changes (by mary.ietf.barnes@gmail.com): * severity: - => Candidate WG Document Old description: > What transport protocol should be used for the CLUE specific signaling > information? New description: What transport protocol should be used for the CLUE specific signaling information? To be resolved in clue-data-channel document -- -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:05:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34B511E8196 for ; Thu, 31 Oct 2013 08:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppTIiaVsx7s1 for ; Thu, 31 Oct 2013 08:05:54 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CCA8621E809A for ; Thu, 31 Oct 2013 08:05:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:51182 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbtoP-0003cx-2p; Thu, 31 Oct 2013 16:05:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:05:29 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/14#comment:3 Message-ID: <083.bd5907b482a6935996717cbd0e829800@trac.tools.ietf.org> References: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <068.890588ccdb9d1a0b74f5999dd9ddcd35@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031150531.CCA8621E809A@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 08:05:31 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #14: How do we transport the CLUE information? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:06:00 -0000 #14: How do we transport the CLUE information? Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Old description: > What transport protocol should be used for the CLUE specific signaling > information? > > To be resolved in clue-data-channel document New description: What transport protocol should be used for the CLUE specific signaling information? -- Comment: This issue was resolved by the WG decision to use SCTP/DTLS/UDP as the transport protocol. This will be discussed in the clue-signaling and clue-protocol documents, with the details to be provided in the clue-data- channel document -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: closed Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:07:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4911E8171 for ; Thu, 31 Oct 2013 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbku4LtzbmSi for ; Thu, 31 Oct 2013 08:07:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 18C8111E8125 for ; Thu, 31 Oct 2013 08:07:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:51356 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbtqk-0003cd-Co; Thu, 31 Oct 2013 16:07:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:07:54 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/20#comment:6 Message-ID: <083.2aa12f998823bbcaf499491928df6d9b@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:07:55 -0000 #20: Action item vii: Rejecting Configure Description changed by mary.ietf.barnes@gmail.com: Old description: > Action item vii from 19-20 Sept. 2012 interim. > > Andy: Add text to Framework for rejecting Configure > > As discussed at virtual interim on May 21st, 2013: > http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- > interim-2013-clue-1 > this needs to be mentioned in the framework, so that the subsequent > actions can be described. (E.g., does the prior configure remain in > effect?) > > The details of how this is communicated belong in the solution. > > As discussed at IETF-87, this ticket is being reassigned to the > signaling/solution document (being parked as a charter item until we have > a WG signaling document. New description: Action item vii from 19-20 Sept. 2012 interim. Andy: Add text to Framework for rejecting Configure As discussed at virtual interim on May 21st, 2013: http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- interim-2013-clue-1 this needs to be mentioned in the framework, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. As discussed at IETF-87, this ticket is being reassigned to the signaling/solution document (being parked as a charter item until we have a WG signaling document. With new WG milestones, defined this issue will be resolved in the clue- protocol document -- -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mary.ietf.barnes@gmail.com Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:09:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6775211E8175 for ; Thu, 31 Oct 2013 08:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 630hoanWK2xg for ; Thu, 31 Oct 2013 08:09:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C0BAD21E80ED for ; Thu, 31 Oct 2013 08:09:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:51367 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbtrp-000693-SJ; Thu, 31 Oct 2013 16:09:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: roberta.presta@unina.it, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:09:01 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/20#comment:7 Message-ID: <083.02f94a59a7ed309ab800c79922e595f1@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: roberta.presta@unina.it, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:09:22 -0000 #20: Action item vii: Rejecting Configure Changes (by mary.ietf.barnes@gmail.com): * owner: mary.ietf.barnes@gmail.com => roberta.presta@unina.it -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | roberta.presta@unina.it Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:11:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A655E11E8232 for ; Thu, 31 Oct 2013 08:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYErQ+ski7qR for ; Thu, 31 Oct 2013 08:11:11 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 454E311E8226 for ; Thu, 31 Oct 2013 08:11:06 -0700 (PDT) Received: from localhost ([127.0.0.1]:51470 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Vbtto-0007pN-Td; Thu, 31 Oct 2013 16:11:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:11:04 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/28#comment:1 Message-ID: <083.883d541c429fbced013110d461a6b443@trac.tools.ietf.org> References: <068.16d36ac893f61090f351de0e3f0fd234@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <068.16d36ac893f61090f351de0e3f0fd234@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031151106.454E311E8226@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 08:11:06 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #28: Configure message & SDP consistency X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:11:11 -0000 #28: Configure message & SDP consistency Changes (by mary.ietf.barnes@gmail.com): * severity: - => Candidate WG Document Old description: > Issue d from the 19-20 Sept 2012 interim. > > Must the configure message be consistent with the current SDP? > Needs further consideration….e.g. order that things are changed, etc. > Overarching objective is to minimize what info might be duplicated. New description: Issue d from the 19-20 Sept 2012 interim. Must the configure message be consistent with the current SDP? Needs further consideration….e.g. order that things are changed, etc. Overarching objective is to minimize what info might be duplicated. The resolution will be documented in the clue-signaling WG deliverable -- -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Thu Oct 31 08:15:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D1611E821E for ; Thu, 31 Oct 2013 08:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAsUmk3G1hZy for ; Thu, 31 Oct 2013 08:14:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1934E11E8172 for ; Thu, 31 Oct 2013 08:14:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:51933 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VbtxV-0007c2-I4; Thu, 31 Oct 2013 16:14:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Thu, 31 Oct 2013 15:14:53 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/clue/trac/ticket/29#comment:3 Message-ID: <083.b2430085d74939a522da68a367e0c250@trac.tools.ietf.org> References: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20131031151455.1934E11E8172@ietfa.amsl.com> Resent-Date: Thu, 31 Oct 2013 08:14:55 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #29: Mechanism to know which m-lines are under CLUE control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 15:15:04 -0000 #29: Mechanism to know which m-lines are under CLUE control Changes (by mary.ietf.barnes@gmail.com): * severity: - => Candidate WG Document Old description: New description: Issue e from 19-20 Sept. 2012 interim. Note: this relates to Ticket #23 (Action item). Need a mechanism to know which m-lines are under CLUE control within SDP. Also, need to define how this works within O/A. This will be resolved in the clue-signaling WG document, however, there are dependencies on MMUSIC WG items (Ticket #23). -- -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: Signaling | -------------------------------------+------------------------------------- Ticket URL: clue


      On Wed, Oct 2, 2013 at 9:12 AM, DRAGE, Keith (Keit= h) <keith.drage@alcatel-lucent.com> wrote:

      Just to add a pedantic point,= I am not sure what a =93non-CLUE=94 is. What we have is something where CL= UE does not exist, not the creation of some other concept of a =93non-CLUE=94 to complement a =93CLUE=94. You = want to apply the negation to the =93enabled=94 which is something like =93= disabled=94, =93unenabled=94 or whatever.

      =A0

      Keith

      =A0

      From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of Mary Barnes
      Sent: 02 October 2013 14:57<= br> To: Paul Coverdale
      Cc: CLUE


      Subject: Re: [clue] Its not = "legacy", its ???
      <= u>

      =A0

      It is a fine line. =A0I personally have a preference= for "non-CLUE enabled". =A0 I really don't think we'll b= e using that in too many places in the documents that it's too much typing. =A0If someone thinks that's the case, perhaps we use &quo= t;clueless" in the docs until we're ready to ship them out of the = WG and then just do a global change. =A0As I've said before for XCON, w= e do use the term "non-XCON enabled" which I think has the right semantics and really isn't too much of a mouthful to say either.=

      =A0

      Mary.=A0

      =A0

      On Wed, Oct 2, 2013 at 8:35 AM, Paul Coverdale <coverdale@sympatico.ca> wrote:<= /u>

      I thought the proposal of "clueless' was ju= st a joke when I first saw it,
      but apparently not.

      I think this term will just invite ridicule. It's a bit of a mouthful, = but I
      would suggest "non-CLUE" equipped". But if you insist on usi= ng "clueless",
      at least hyphenate it (clue-less).

      ...Paul


      >-----Original Message-----
      >From: clue-b= ounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of

      >Paul Kyzivat
      >Sent: Tuesday, October 01, 2013 5:40 PM
      >To: clue@ietf.org
      >Subject: Re: [clue] Its not "legacy", its ???
      >

      >On 10/1/13 12:45 PM, Robert Hansen wrote:
      >> I am personally very fond of 'CLUEless' :)
      >
      >One of the reasons I liked the name "clue" for the wg was bec= ause it
      >gave us an excuse to use "clueless" and "clueful". = However they do have
      >the feel of "informal" usage - a bit odd for formal use. (But= I can get
      >over that.)
      >
      > =A0 =A0 =A0 Thanks,
      > =A0 =A0 =A0 Paul
      >
      >> Rob
      >>
      >> On 01/10/2013 17:22, Paul Kyzivat wrote:
      >>> Mary,
      >>>
      >>> The minutes are now posted. We did talk about this, briefly. >>> We decided we didn't want to use the meeting time to discu= ss what
      >>> word to use - that we could do that on the list.
      >>>
      >>> I agree with you, I also think "legacy" has the wron= g connotation for
      >>> what we mean, so I would like to find a better term. I have no= ideas
      >>> that I love, but a couple that I could live with: "non-cl= ue",
      >"clueless".
      >>>
      >>> =A0 =A0 =A0Thanks,
      >>> =A0 =A0 =A0Paul
      >>>
      >>> On 10/1/13 10:26 AM, Mary Barnes wrote:
      >>>> I'm in another meeting so unfortunately cannot attend = today. =A0But, I
      >>>> would really, really like to get away from the term "= legacy" - =A0the
      >>>> English language definition of "legacy" is not c= orrect. CLUE isn't
      >>>> superseding any functionality of current SIP endpoints. = =A0It's adding
      >>>> additional functionality. I would much rather select somet= hing like
      >>>> "non-Clue enabled endpoint". =A0 We can shorten = if folks are concerned
      >>>> about the length of a more appropriate alternative term. >>>>
      >>>> As an aside, IMHO, the RTCWEB folks using the term "l= egacy" is
      >>>> slightly more appropriate since it's a different archi= tecture and
      >>>> entirely new application - i.e., it isn't based on RFC= 3261, but
      >>>> CLUE is, so any suggestion that it's replacing any cur= rent SIP
      >>>> functionality isn't correct.
      >>>>
      >>>> Regards,
      >>>> Mary.
      >>>>
      >>>>
      >>>> On Tue, Oct 1, 2013 at 8:19 AM, Paul Kyzivat <      pkyzivat@alum.mit.edu
      >>>> <mailto:      pkyzivat@alum.mit.edu>> wrote:
      >>>>
      >>>> =A0 =A0 You can find Christer's slides for today at: >>>>
      >>>>

      >>>> /CLUE_Legacy_1oct13.pptx>
      >>>>
      >>>>
      >>>>
      >>>> =A0 =A0 See you shortly.
      >>>>
      >>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
      >>>> =A0 =A0 _________________________________________________<= br> >>>> =A0 =A0 clue mailing list
      >>>> =A0 =A0 clue@ietf.org <mailto:clue@ietf.org>
      >>>> =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue >>>> =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue&g= t;
      >>>>
      >>>>
      >>>
      >>> _______________________________________________
      >>> clue mailing list
      >>> clue@ietf.o= rg
      >>> https://www.ietf.org/mailman/listinfo/clue
      >>
      >> _______________________________________________
      >> clue mailing list
      >> clue@ietf.org
      >>       https://www.ietf.org/mailman/listinfo/clue
      >>
      >
      >_______________________________________________
      >clue mailing list
      >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue

      _______________________________________________
      clue mailing list
      clue@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/clue

      =A0