From Mark.Duckworth@polycom.com Fri Nov 1 07:00: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 C86F111E8381 for ; Fri, 1 Nov 2013 07:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 DuTQlG1XI7y3 for ; Fri, 1 Nov 2013 06:59:51 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B805111E8391 for ; Fri, 1 Nov 2013 06:59:48 -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, 1 Nov 2013 06:59:47 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Fri, 1 Nov 2013 06:59:45 -0700 Thread-Topic: [clue] comments on draft-ietf-clue-framework-12 Thread-Index: Ac7TND1neWEG9iXGQYuD62W3Mo9P8gD0XKTQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D603EECDC6@CRPMBOXPRD07.polycom.com> References: <526D4398.6030701@alum.mit.edu> In-Reply-To: <526D4398.6030701@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] 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: Fri, 01 Nov 2013 14:00:10 -0000 Hi Paul, Thanks for the feedback. I particularly appreciate feedback on the topic of= normative language and RFC 2119 keywords, because this area is new to me. My comments inline below. I'd like to see Stephan's comments too, as he made most of the updates rela= ted to the RFC 2119 keywords. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Sunday, October 27, 2013 12:47 PM > To: CLUE > Subject: [clue] comments on draft-ietf-clue-framework-12 >=20 > 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 sho= uld > be possible to deal with them all via email. >=20 > 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 ou= t the > specific points where I see this below. >=20 >=20 > Section 5 says: >=20 > 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. >=20 > I think this is a bit too strong. While it is *likely* that another O/A e= xchange > will be needed, I don't think it is mandatory. If it turns out that the S= DP > already in effect is sufficient, then no new O/A is needed. > A degenerate case of this is when nothing is configured. >=20 > I suggest replacing "MUST be" by "will usually be" [Duckworth, Mark] That seems okay to me. > Later in the section: >=20 > 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. >=20 > 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". [Duckworth, Mark] That seems okay to me. > Later in the section: >=20 > 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. >=20 > 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 b= e > said about that, it might be something about "mandatory to implement, > optional to use". [Duckworth, Mark] "MUST follow the CLUE protocol" seems correct, but maybe = redundant. I agree we are not sure yet if that means is must send a configu= re msg, so that might have to change. Your suggestion "mandatory to implement, optional to use" might be a better= way of stating the intent of the second sentence in the paragraph. > Still later: >=20 > 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. >=20 > 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. [Duckworth, Mark] That seems okay to me. > Section 6: >=20 > 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'. >=20 > 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. [Duckworth, Mark] Stephan said in general we should avoid using "SHOULD", s= o that's what we did. It's fine with me if we change this one to SHOULD or = even MAY. > 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. >=20 > Section 7.3: >=20 > 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. >=20 > 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. >=20 > But when I read the 2nd sentence, then I conclude that something weaker i= s > being implied - that by default simultaneity is required between any arbi= trary > choice of a single CSE from each scene. >=20 > 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. [Duckworth, Mark] Good point. The intent is the second thing you said. I'll= make a note to clarify this in the next version. > Section 10: >=20 > 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. >=20 > I don't think this is accurate when Encodings are represented in SDP. I w= on't > attempt to wordsmith a revision here - it may require a substantial rewri= te. [Duckworth, Mark] I think we should fix this paragraph after the protocol d= ocuments become more stable. I'll make a note of it. > Thanks, > Paul (as individual) From mary.ietf.barnes@gmail.com Fri Nov 1 10:56: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 0341111E8173 for ; Fri, 1 Nov 2013 10:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 BBWUQ2Zcc9RP for ; Fri, 1 Nov 2013 10:56:50 -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 C4F4A11E8230 for ; Fri, 1 Nov 2013 10:56:49 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id ex4so1427537wid.14 for ; Fri, 01 Nov 2013 10:56:49 -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=6NHhEI7AVMPdOl4IL54NuDwWe7a7ye1aH8v03LeHRvc=; b=xB261eYIFNl6iFyo3YyCTN2PZ6fA1hIl6hJmYovJ/JbeSYwSwY+e1X7z5iqCTOW5l7 EX53hFGhSO2d99quTrDWC5+oVOv9LODBk1MVIDoGXP+LMNHzNubU8B7mAK6zwWUclrrn JNCkKvv+0JDsBBIp7YEciU1uDZ+veIMR/EUG7L0XWO7oRPkDwVskAQ4TX7f6Ui2z4caB MDjbegSKeKKo6eCVi5SNeqY4GTOfSIWOCFhivUoay7TK5xvsKvgRqSBtMpf4evRW8Qy7 +F/Hpf1h24tOtbumpToct3xLBAijI+3mIAv4FgBQxNUR8IqKEGV23NIj3pR3YeAeVbUs 7jEg== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr3130365wic.33.1383328608981; Fri, 01 Nov 2013 10:56:48 -0700 (PDT) Received: by 10.216.36.4 with HTTP; Fri, 1 Nov 2013 10:56:48 -0700 (PDT) Date: Fri, 1 Nov 2013 12:56:48 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3844c589b3204ea214af4 Subject: [clue] Doodle: Link for poll "CLUE WG (Informal) Dinner" 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, 01 Nov 2013 17:56:51 -0000 --001a11c3844c589b3204ea214af4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, As usual, I'd like to propose an informal CLUE WG dinner in Vancouver. I've setup a doodle to get a headcount and preferred time: http://doodle.com/4hyzwyf7yrh3ahmr I chose Tuesday as there is no social and it's one of the early ending days (i.e., 1840 rather than 1940). Please respond to the doodle no later than noon on Monday, Nov 4th, so I can get a reservation somewhere. Thanks, Mary. --001a11c3844c589b3204ea214af4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

As usual, I'd like to propo= se an informal CLUE WG dinner in Vancouver. =A0I've setup a doodle to g= et a headcount and preferred time:
http://doodle.com/4hyzwyf7yrh3ahmr
I chose Tuesday as there is no social and =A0it's one of the early endi= ng days (i.e., 1840 rather than 1940). =A0Please respond to the doodle no l= ater than noon on Monday, Nov 4th, so I can get a reservation somewhere. = =A0

Thanks,
Mary.

--001a11c3844c589b3204ea214af4-- From spromano@unina.it Mon Nov 4 15:25: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 F148411E821A for ; Mon, 4 Nov 2013 15:25:22 -0800 (PST) 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=[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 YspEcEvvtLos for ; Mon, 4 Nov 2013 15:25:18 -0800 (PST) Received: from relay1.tre.it (relay1.tre.it [62.13.171.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9AC21E80F9 for ; Mon, 4 Nov 2013 15:25:14 -0800 (PST) Received: from [192.168.1.100] ([10.86.92.8]) by relay1.tre.it with ESMTP id rA4NPBo0017157-rA4NPBo1017157 for ; Tue, 5 Nov 2013 00:25:12 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_CBB6C807-DC42-4644-A765-A3A439548EFE" Date: Tue, 5 Nov 2013 00:25:11 +0100 References: <20131104231708.10133.4005.idtracker@ietfa.amsl.com> To: CLUE Message-Id: <1D51726E-3722-482A-9537-F6FCC5954515@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-03.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, 04 Nov 2013 23:25:23 -0000 --Apple-Mail=_CBB6C807-DC42-4644-A765-A3A439548EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 FYI (and in view of tomorrow's discussion). Simon Inizio messaggio inoltrato: > Da: internet-drafts@ietf.org > Oggetto: New Version Notification for = draft-presta-clue-protocol-03.txt > Data: 05 novembre 2013 00:17:08 GMT+01:00 > A: Roberta Presta , Simon Pietro Romano = , Simon Romano >=20 >=20 > A new version of I-D, draft-presta-clue-protocol-03.txt > has been successfully submitted by Roberta Presta and posted to the > IETF repository. >=20 > Filename: draft-presta-clue-protocol > Revision: 03 > Title: CLUE protocol > Creation date: 2013-11-05 > Group: Individual Submission > Number of pages: 31 > URL: = http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-03.txt > Status: = http://datatracker.ietf.org/doc/draft-presta-clue-protocol > Htmlized: = http://tools.ietf.org/html/draft-presta-clue-protocol-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-presta-clue-protocol-03 >=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 into the SIP/SDP session establishment phase. We herein > focus on the application level perspective. Message details, > together with the behavior of CLUE participants acting as Media > Providers and/or Media Consumers, 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=_CBB6C807-DC42-4644-A765-A3A439548EFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 FYI = (and in view of tomorrow's = discussion).

Simon

Inizio messaggio = inoltrato:

Oggetto: New Version Notification for = draft-presta-clue-protocol-03.txt
Data: 05 novembre 2013 = 00:17:08 GMT+01: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-03.txt
has been successfully submitted by = Roberta Presta and posted to the
IETF = repository.

Filename: = draft-presta-clue-protocol
Revision: 03
Title: CLUE = protocol
Creation date: 2013-11-05
Group: = Individual Submission
Number of pages: 31
URL: =             http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-03.txt=
Status:          http:/= /datatracker.ietf.org/doc/draft-presta-clue-protocol
Htmlized: =        http://t= ools.ietf.org/html/draft-presta-clue-protocol-03
Diff: =            = http://www.ietf.org/rfcdiff?url2=3Ddraft-presta-clue-protocol-03
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 into the SIP/SDP = session establishment phase.  We herein
  focus on = the application level perspective.  Message details,
=   together with the behavior of CLUE participants acting as = Media
  Providers and/or Media Consumers, 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=_CBB6C807-DC42-4644-A765-A3A439548EFE-- From ron.even.tlv@gmail.com Tue Nov 5 09:13: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 67E6B11E80D9 for ; Tue, 5 Nov 2013 09:13:43 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-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 25nkJ1kv08vv for ; Tue, 5 Nov 2013 09:13:42 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id AF5F221E811F for ; Tue, 5 Nov 2013 09:13:38 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id z20so1834673yhz.26 for ; Tue, 05 Nov 2013 09:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=spXyXnfgcw8IFRyFlo0tg9CXCkT7T7NMWH+Uls7CfR4=; b=BnD1ze8btDXIbv1hKvofOs7eqjVlBWr2Iq/+/YOYZMBv3MtkD70uDwavxosmZewOdo 8ljo20YCCN0q2VucjMqaQGMOqOZa6/wx09J9TTcXgH9uWCfpPpDGrtiZofcVJLDGUaHg 3vayLjNewrTeC8GXrJ+uN7SxPncW/69qVCpf+8JvjSOFqSmte2yWRN2LD//+gHzVbjuY LILXIEFmofEVpNiD5aLYkWTyak5dcQGOpsu7p0vOj0F3kmB8320V8JE+R5sWAOEwT1zl 9B3Ea5iq6khuXiG/ewewZqQFq5hQIWuGBANWA0rtkEAcJwmqMh09pYluOqnla6OwzaCn QGpQ== X-Received: by 10.236.57.135 with SMTP id o7mr650352yhc.138.1383671618114; Tue, 05 Nov 2013 09:13:38 -0800 (PST) Received: from RoniE ([2001:67c:370:160:5931:63fe:a028:4423]) by mx.google.com with ESMTPSA id e10sm37671015yhj.1.2013.11.05.09.13.35 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Nov 2013 09:13:37 -0800 (PST) From: "Roni Even" To: Date: Tue, 5 Nov 2013 19:10:19 +0200 Message-ID: <04a001ceda49$ea007790$be0166b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04A1_01CEDA5A.AD8995B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7aSYpT/Wv0O374RwGTJleT8D4X6g== Content-Language: en-us Subject: [clue] other related documents 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, 05 Nov 2013 17:13:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04A1_01CEDA5A.AD8995B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There are other documents that may be of interest to the CLUE signaling http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-03 http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcname-03 Roni Even ------=_NextPart_000_04A1_01CEDA5A.AD8995B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There are other = documents that may be of interest to the CLUE signaling =

 

http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-03=

 

http://tools.ietf.org/html/draft-westerlund-avtext-rtcp-sdes-srcn= ame-03

 

Roni Even

------=_NextPart_000_04A1_01CEDA5A.AD8995B0-- From eckelcu@cisco.com Tue Nov 5 11: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 08F9421F9DED for ; Tue, 5 Nov 2013 11:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=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 gU0Sbu6NAH3l for ; Tue, 5 Nov 2013 11:54:13 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1F40211E8159 for ; Tue, 5 Nov 2013 11:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1383681158; x=1384890758; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Qb9oUdlKI0LJaNtXxn7dABkJZWE0ilL8HLu60hgX5WE=; b=ZJ09aXhwErwjzUyaatofJa3nREARa07zhi3+RqpO3fjKB3WDuNH+YQDr /RySv6PjVXZIbFSMdzcJBETk6K4ACxP2P/HH5x77uNzQ31De75FO8n3GF Rd5leolVTrTl07LfZfMo3wz1RX7EWI2X+CunfK+gmoOcfdh2SLFX/JOjj A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQHAE1LeVKtJXG+/2dsb2JhbABZgwc4U75vgXcWbQeCLDpRAT5CJwSIFA2dIqFUlA8DmAqBL5BagyaCKg X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208";a="281094836" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2013 19:52:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5JqRFh025703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Nov 2013 19:52:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:52:27 -0600 From: "Charles Eckel (eckelcu)" To: "clue@ietf.org" Thread-Topic: interworking with non-CLUE devices Thread-Index: AQHO2mCN1SDWAJrGBUy4K8gfbZdGMQ== Date: Tue, 5 Nov 2013 19:52:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.115.31] Content-Type: text/plain; charset="us-ascii" Content-ID: <6646F870E17BEA4AA81F45727AF1B8AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 05 Nov 2013 11:57:12 -0800 Subject: [clue] interworking with non-CLUE devices 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, 05 Nov 2013 19:54:20 -0000 Based on the discussion in today's meeting, I think it would be useful for folks to have a look at the IMTC SIP Parity SIP Video Profile and Role Based Video best practices. The SIP Video Profile provides guidelines for H.264 video streams. http://portal.imtc.org/DesktopModules/Inventures_Document/FileDownload.aspx ?ContentID=3D21434 "Best Practices for Role?Based Video Streams (RBVS) in SIP" provides guidelines for adding content sharing. https://datatracker.ietf.org/documents/LIAISON/liaison-2012-05-31-imtc-the- ietf-imtc-work-on-sip-feature-parity-with-h323-attachment-3.pdf Cheers, Charles From Mark.Duckworth@polycom.com Tue Nov 5 16:56: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 AC4A011E8199 for ; Tue, 5 Nov 2013 16:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.565 X-Spam-Level: X-Spam-Status: No, score=-6.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 DbvqPQiuFDIe for ; Tue, 5 Nov 2013 16:56:13 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id AC25411E81C3 for ; Tue, 5 Nov 2013 16:56:12 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 5 Nov 2013 16:56:12 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 5 Nov 2013 16:56:09 -0800 Thread-Topic: Framework discussion for Friday Thread-Index: Ac7aitZ6unLjbL2rRV+4XYMf8zxikw== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D603EEDB72@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_49E45C59CA48264997FEBFB29B6BC2D603EEDB72CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Framework discussion for Friday 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, 06 Nov 2013 00:56:18 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D603EEDB72CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For Friday's framework discussion, the major topics are Multiple Content Ca= pture and how to manage streams with a media switching mixer. This is base= d on these drafts: - draft-groves-clue-multi-content-00 - draft-duckworth-clue-switching-example-01 We have had some discussion on the email list, which we can continue on Fri= day. I will update my presentation to include more about the media switching sce= nario, and how MCC might help. I hope to have it ready by Wednesday aftern= oon. I see three basic ways it could be done: 1. Provider (mixer) makes switching decisions, mixer's advertisement has on= e big capture scene with many MCCs, plus other information about the origin= al source scenes and captures. 2. Consumer (terminal) makes switching decisions, mixer's advertisement has= one big capture scene with many MCCs, plus other information about the ori= ginal source scenes and captures. (I proposed this on email list, it is not= in the draft). 3. Provider (mixer) makes switching decisions, mixer's advertisement has se= veral smaller scenes with spatial information. On Friday, I'd like to see if the group agrees on which one (or more) of th= ese approaches should be supported by CLUE, and what additional work, if an= y, we need to do in CLUE or other working groups to make it work. Mark --_000_49E45C59CA48264997FEBFB29B6BC2D603EEDB72CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For Friday's fra= mework discussion, the major topics are Multiple Content Capture and how to= manage streams with a media switching mixer.  This is based on these = drafts:

- draft-groves-clue-multi-conten= t-00

- draft-duckworth-clue-switching-ex= ample-01

 

We have had some discussion on the email list, which we can co= ntinue on Friday.

 

<= p class=3DMsoNormal>I will update my presentation to include more about the= media switching scenario, and how MCC might help.  I hope to have it = ready by Wednesday afternoon.  I see three basic ways it could be done= :

 

1. Provider (mixer) makes switching decisions, mixer's advertisement ha= s one big capture scene with many MCCs, plus other information about the or= iginal source scenes and captures.

2. Co= nsumer (terminal) makes switching decisions, mixer's advertisement has one = big capture scene with many MCCs, plus other information about the original= source scenes and captures. (I proposed this on email list, it is not in t= he draft).

3. Provider (mixer) makes swi= tching decisions, mixer's advertisement has several smaller scenes with spa= tial information.

 

<= p class=3DMsoNormal>On Friday, I'd like to see if the group agrees on which= one (or more) of these approaches should be supported by CLUE, and what ad= ditional work, if any, we need to do in CLUE or other working groups to mak= e it work.

 

Mark

= --_000_49E45C59CA48264997FEBFB29B6BC2D603EEDB72CRPMBOXPRD07pol_-- From spromano@unina.it Fri Nov 8 10:31: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 1D96621E8099 for ; Fri, 8 Nov 2013 10:31:53 -0800 (PST) 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=[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 5MknrQK1Doag for ; Fri, 8 Nov 2013 10:31:47 -0800 (PST) Received: from smtp208.alice.it (smtp208.alice.it [82.57.200.104]) by ietfa.amsl.com (Postfix) with ESMTP id 906F421E80B6 for ; Fri, 8 Nov 2013 10:31:41 -0800 (PST) Received: from [192.168.1.100] (79.51.40.186) by smtp208.alice.it (8.6.060.28) id 52443B820B1FE8ED; Fri, 8 Nov 2013 19:31:31 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_56651449-9A18-4E73-B909-E3AD10B4E322" Date: Fri, 8 Nov 2013 19:31:46 +0100 Message-Id: To: CLUE Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: Roberta Presta Subject: [clue] Expressing encoding limits 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, 08 Nov 2013 18:31:53 -0000 --Apple-Mail=_56651449-9A18-4E73-B909-E3AD10B4E322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, as to the topic in the subject, I would just like to express my opinion = here on the list, since I am not sure I'll be able to attend today's = session remotely. Indeed, I'd be interested in investigating the = possibility of conveying such limits in the CLUE channel, starting from = the information we have inserted in the data model schema. If some of = you think this is worth a try, we can devote some cycles to tackling = this issue. Simon _\\|//_ ( 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=_56651449-9A18-4E73-B909-E3AD10B4E322 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = all,

as to the topic in the subject, I would just = like to express my opinion here on the list, since I am not sure I'll be = able to attend today's session remotely. Indeed, I'd be interested in = investigating the possibility of conveying such limits in the CLUE = channel, starting from the information we have inserted in the data = model schema. If some of you think this is worth a try, we can devote = some cycles to tackling this = issue.

Simon
      =                 =    =     _\\|//_
          =                   =       ( 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=_56651449-9A18-4E73-B909-E3AD10B4E322-- From pkyzivat@alum.mit.edu Fri Nov 8 14:36: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 C860D21E8085 for ; Fri, 8 Nov 2013 14:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 9YkgC6SGIbV4 for ; Fri, 8 Nov 2013 14:36:52 -0800 (PST) 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 F3C2621E805F for ; Fri, 8 Nov 2013 14:36:50 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id n3Ef1m0011YDfWL54Acqm1; Fri, 08 Nov 2013 22:36:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([209.82.80.116]) by omta20.westchester.pa.mail.comcast.net with comcast id nAai1m00E2WaMRd3gAakD5; Fri, 08 Nov 2013 22:34:48 +0000 Message-ID: <527D6701.5070206@alum.mit.edu> Date: Fri, 08 Nov 2013 14:34:41 -0800 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=1383950210; bh=hO825+O8cAUIsyhd8excopG+3AkSoi8xcQUTrCo8mcQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C/su8Vwxnn58LmhRgI+SQF/wtseOXslDSNj0lLCbUH+y9KwP96BlkU2u0TGeWyr5W Ar0T9qodhyIt+6lre3qRwUB7HgN6yXw8Dc+dG8gG+DtNr/OLlxV6JdmLyp1xh/JAPE BOhb6fw4OU/EG80lXJrZ9bRhFuzhyhud5Dlq7emBOmv8ErRng6ycFWrRM/HRWSTU12 dOwYdwX+qOtvYrmuRSMWEH+HOO15ORvGyGXSbALTXJrAhHK4lk9KnjPWVopa9h8Pmh RN+vPLd5LqibkmfF8RLvRp/rqVILig1SMyv479bjOAHTwBL7ikFfr99M+v89n6qFw4 vMQaZIhrhf7OQ== Subject: [clue] clue minutes 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, 08 Nov 2013 22:36:58 -0000 I have dumped the raw meeting notes from Paul Coverdale, Keith Drage, and Richard Ejzak into the minutes file, http://www.ietf.org/proceedings/88/minutes/minutes-88-clue so that there is *something* there. As yet I have not reviewed them. You can expect these to be revised later. Thanks, Paul From ietf-ipr@ietf.org Tue Nov 12 09:46: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 D36E721E80B4; Tue, 12 Nov 2013 09:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.316 X-Spam-Level: X-Spam-Status: No, score=-102.316 tagged_above=-999 required=5 tests=[AWL=0.284, 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 2Td6xpbCxahU; Tue, 12 Nov 2013 09:46:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0824B21E80D2; Tue, 12 Nov 2013 09:44:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: apeppere@gmail.com,mark.duckworth@polycom.com,stewe@stewe.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131112174427.11559.34739.idtracker@ietfa.amsl.com> Date: Tue, 12 Nov 2013 09:44:27 -0800 Cc: clue@ietf.org, ipr-announce@ietf.org Subject: [clue] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-clue-framework-12 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: Tue, 12 Nov 2013 17:46:26 -0000 Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger: An IPR disclosure that pertains to your Internet-Draft entitled "Framework= for Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted to the IETF Secretariat on 2013-11-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2244/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- ietf-clue-framework-12.""); The IETF Secretariat From mary.ietf.barnes@gmail.com Thu Nov 14 11:54:10 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 7CCB021F9D19 for ; Thu, 14 Nov 2013 11:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.637 X-Spam-Level: X-Spam-Status: No, score=-101.637 tagged_above=-999 required=5 tests=[AWL=-0.704, 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 gNUo4np0TojQ for ; Thu, 14 Nov 2013 11:54:10 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1121F9CBF for ; Thu, 14 Nov 2013 11:54:09 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id i19so3167256wiw.11 for ; Thu, 14 Nov 2013 11:54:08 -0800 (PST) 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=ZgKHlZ7Fs6x46OzNGQG2QXjAlFgP8964cjvCJN6Yzh4=; b=lsw9pciDhg+667EKB3ZOtA3P3wLY5BxRVgiD9KNv7AMU32Qm0mh8jz69As5r7H74LM B7U8kyhukO7ku5I/TLGdNmnMRSif+kOBjWIIE8xf7yrbkN5tU0F+PEupk6lX+gsgnvce 15l2CoHhP23rQUyGg/ImlXnsNQM6XamoufMGKi5QvF4AuWor1YeQuCnFFuOquOnNHEl5 u63kbrl8F2guEi7z4sa1qDgJ8TBTOrqkMKrIldwS8F7gshl3I6RxC1vfZXr5Ddd42wub KezSn+wv7J0FVG4T+CCIPrCGESkMYIQ80ZqdALI7ctJbjNUTe8NAnaQw1eNvs3m4f8Mf nTRQ== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr3612691wjb.21.1384458848825; Thu, 14 Nov 2013 11:54:08 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 14 Nov 2013 11:54:08 -0800 (PST) In-Reply-To: <527D6701.5070206@alum.mit.edu> References: <527D6701.5070206@alum.mit.edu> Date: Thu, 14 Nov 2013 13:54:08 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e011779b5e41cac04eb2871b4 Cc: CLUE Subject: Re: [clue] clue minutes 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, 14 Nov 2013 19:54:10 -0000 --089e011779b5e41cac04eb2871b4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The minutes have been updated to include Brian Rosen's notes from etherpad (a very handy way to capture minutes) and a summary section along with action items. Please review that carefully as there are near term deadlines for many of the action items. Also, any comments or proposed updates to the minutes should be provided no later than Friday November 22nd. While we are getting into the holiday season, we really need to continue making progress through the year end, so we can be off to a quick start in 2014, with the objective of finishing our major milestones by the end of 2014. I am anticipating that we will not have a design team call next Tuesday unless there is a topic for which someone is willing to kick off discussion now and then lead the discussion next Tuesday. I will post the proposed topics for upcoming DT meetings on the wiki. Note that the topics may change depending upon the order in which documents get updated and mailing list discussions emerge. Thanks, Mary. On Fri, Nov 8, 2013 at 4:34 PM, Paul Kyzivat wrote: > I have dumped the raw meeting notes from Paul Coverdale, Keith Drage, and > Richard Ejzak into the minutes file, > > http://www.ietf.org/proceedings/88/minutes/minutes-88-clue > > so that there is *something* there. As yet I have not reviewed them. You > can expect these to be revised later. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e011779b5e41cac04eb2871b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The minutes have been upd= ated to include Brian Rosen's notes from etherpad (a very handy way to = capture minutes) and a summary section along with action items. =A0Please r= eview that carefully as there are near term deadlines for many of the actio= n items. =A0Also, any comments or proposed updates to the minutes should be= provided no later than Friday November 22nd. =A0

While we are getting into the holiday seaso= n, we really need to continue making progress through the year end, so we c= an be off to a quick start in 2014, with the objective of finishing our maj= or milestones by the end of 2014. =A0=A0

I am anticipating that we will not have a d= esign team call next Tuesday unless there is a topic for which someone is w= illing to kick off discussion now and then lead the discussion next Tuesday= . =A0I will post the proposed topics for upcoming DT meetings on the wiki. = =A0Note that the topics may change depending upon the order in which docume= nts get updated and mailing list discussions emerge.=A0

Thanks,
Mary.=A0


On Fri, Nov = 8, 2013 at 4:34 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= wrote:
I have dumped the raw meeting notes from Pau= l Coverdale, Keith Drage, and Richard Ejzak into the minutes file,

http://www.ietf.org/proceedings/88/minutes/minu= tes-88-clue

so that there is *something* there. As yet I have not reviewed them. You ca= n expect these to be revised later.

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

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

--089e011779b5e41cac04eb2871b4-- From mary.ietf.barnes@gmail.com Thu Nov 14 15:01: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 88CF111E8123 for ; Thu, 14 Nov 2013 15:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 rpbLYx3fgaLa for ; Thu, 14 Nov 2013 15:01:52 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB6B11E8112 for ; Thu, 14 Nov 2013 15:01:52 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id b13so2807118wgh.8 for ; Thu, 14 Nov 2013 15:01:51 -0800 (PST) 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=NhErRkDELFMulTcp7tN+T/XWQg0Fv/8m2tiKHHE6zfY=; b=KsxeZtcU1uNuqi2gzV0WX7zvz+fP31eJSa3gCMyiNfWD54apsNwVY38p5FmkRXvXFW nxUBUbDD81oY+4s3FiqlE0+UiWBR82Hdone3dT9x4UFBZwfGg48Ya0Q2skCzJ03PGNen pHiicW40PBjWmvAYBzCVI61stlweAqe9rYXAHm6v2qPwd82e79yi0qsS1uWAzb7OlmYX MKXXSrmubmLO4OgUKkezOBpEHAwfPWkupZBNISHrlGE5SAG1MSnNejFOg92ZH+YwdhhJ xN8NZf3pUBIMeB2NKNAWUZ85rdhqFbOryMq5OelUSFEvzLJqpouBjxTQCCJFBSdcCXHe wziw== MIME-Version: 1.0 X-Received: by 10.180.188.49 with SMTP id fx17mr5044564wic.33.1384470111559; Thu, 14 Nov 2013 15:01:51 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 14 Nov 2013 15:01:51 -0800 (PST) Date: Thu, 14 Nov 2013 17:01:51 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c25bda33a6ae04eb2b11ee Subject: [clue] Upcoming Design Team calls 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, 14 Nov 2013 23:01:53 -0000 --001a11c25bda33a6ae04eb2b11ee Content-Type: text/plain; charset=ISO-8859-1 HI all, Based on discussions last week, I have posted a proposed schedule for upcoming design team calls with proposed leads: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Of course, the order may change based on levels of mailing list discussions and availability of documents/proposals. So, I suggest that the lead contact the chairs no later than 8am Central on the Friday before the DT meeting so we can see if another topic is ready for discussion. If not, we'll cancel for that week. Thanks, Mary. --001a11c25bda33a6ae04eb2b11ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

Based on discussions last= week, I have posted a proposed schedule for upcoming design team calls wit= h proposed leads:

Of course, the order may change based= on levels of mailing list discussions and availability of documents/propos= als. =A0So, I suggest that the lead contact the chairs no later than 8am Ce= ntral on the Friday before the DT meeting so we can see if another topic is= ready for discussion. If not, we'll cancel for that week.=A0

Thanks,
Mary.=A0
--001a11c25bda33a6ae04eb2b11ee-- From mary.ietf.barnes@gmail.com Thu Nov 14 15:19: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 204F121E80EC for ; Thu, 14 Nov 2013 15:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 oCv6IeZSgisZ for ; Thu, 14 Nov 2013 15:19:17 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFF421E80F2 for ; Thu, 14 Nov 2013 15:19:13 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id z12so2829218wgg.19 for ; Thu, 14 Nov 2013 15:19:12 -0800 (PST) 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=+szT5NmkNhn43FyqBTdWvKPKb5RWZQbFrghwWiBGcNg=; b=zUptVqEi5CHtkrU+kPsAcvpxXj+B07BLmh9xovyEfbfZiEAhOlTMWEy8a2y+8rR64Y e3a6kwF2vAL/mZYQUrn+LJswT51VnIKEUr5Bdnrp14APR7QP035UMkHF0xR8I6sL+bJa fRrOEW6g6Kp90Yzxr/wIUSGOkxISn+Mnq5Qj/2ael4CxoUQI9+/XBT3jIH8ZVAxaGwgk pLnulm+4wejnLnNpKJBE5Blwavn5L6wQealQl55MrBO69rs5zR+WOt7aNgoSgKPdEt/E hTN44U+7iYqIXD6iwfgg/oqnbNFmg31kLxuznkVK6FVC5pryn2QfLSMQUt0ZxsfEj/tA SYwA== MIME-Version: 1.0 X-Received: by 10.180.188.49 with SMTP id fx17mr5106603wic.33.1384471152560; Thu, 14 Nov 2013 15:19:12 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 14 Nov 2013 15:19:12 -0800 (PST) In-Reply-To: <286886333.4082010.1384470802557.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <286886333.4082010.1384470802557.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Thu, 14 Nov 2013 17:19:12 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c25bda40110e04eb2b4fb1 Subject: [clue] Fwd: Doodle: Link for poll "CLUE WG Virtual Interim" 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, 14 Nov 2013 23:19:19 -0000 --001a11c25bda40110e04eb2b4fb1 Content-Type: text/plain; charset=ISO-8859-1 HI all, As a point of clarification, while the .ppt presented by the chairs at the Friday CLUE WG session indicated the possibility of a f2f interim meeting before the next IETF, we realize that's probably not practical given the short timeframe between last week's meeting and the March meeting. Instead, we will schedule a virtual interim in the late January timeframe (in addition to the weekly design team meetings which focus on specific issues and are intended for those that are editing documents and contributing to the detailed solution documents). I have setup a poll to figure out a good date/time. I realize that it's a little bit away, but I'm hoping that folks can reserve that time in their calendars to reduce conflicts. If folks could please fill out the doodle poll no later than December 15th, 2013, we can get the date confirmed before everyone takes off for Winter holidays. http://doodle.com/94tcraiw93sgnrf3 Regards, Mary. --001a11c25bda40110e04eb2b4fb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

As a point of clarification, = while the .ppt presented by the chairs at the Friday CLUE WG session indica= ted the possibility of a f2f interim meeting before the next IETF, we reali= ze that's probably not practical given the short timeframe between last= week's meeting and the March meeting. =A0Instead, we will schedule a v= irtual interim in the late January timeframe (in addition to the weekly des= ign team meetings which focus on specific issues and are intended for those= that are editing documents and contributing to the detailed solution docum= ents). =A0=A0

I have setup a poll to figure out a good date/time. =A0I realize that i= t's a little bit away, but I'm hoping that folks can reserve that t= ime in their calendars to reduce conflicts. =A0If folks could please fill o= ut the doodle poll no later than December 15th, 2013, we can get the date c= onfirmed before everyone takes off for Winter holidays.=A0

http://doo= dle.com/94tcraiw93sgnrf3

Regards,
Mary.=A0

--001a11c25bda40110e04eb2b4fb1-- From trac+clue@trac.tools.ietf.org Fri Nov 15 10:13: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 60BA511E81DF for ; Fri, 15 Nov 2013 10:13:39 -0800 (PST) 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 jACVkctYKnVg for ; Fri, 15 Nov 2013 10:13:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDCD11E8171 for ; Fri, 15 Nov 2013 10:13:31 -0800 (PST) Received: from localhost ([127.0.0.1]:41814 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhNtY-0006pL-Sq; Fri, 15 Nov 2013 19:13: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, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 15 Nov 2013 18:13:28 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/15#comment:1 Message-ID: <083.b7cc23097edcfcced3dd371dc162cbf6@trac.tools.ietf.org> References: <068.5466264b635ccb586d60ce5b5ee027f9@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <068.5466264b635ccb586d60ce5b5ee027f9@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: <20131115181335.1DDCD11E8171@ietfa.amsl.com> Resent-Date: Fri, 15 Nov 2013 10:13:31 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #15: What signaling protocol should be used for 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: Fri, 15 Nov 2013 18:13:39 -0000 #15: What signaling protocol should be used for the CLUE information? Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: A new protocol is being defined to carry the CLUE specific signaling that isn't carried in SIP/SDP. The current reference is draft-presta-clue-protocol (pending WG approval). -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: closed Priority: critical | Milestone: milestone1 Component: charter | Version: 1.0 Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Fri Nov 15 10:26: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 2D8D721F9D8E for ; Fri, 15 Nov 2013 10:26:20 -0800 (PST) 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 kehARgqa5yTV for ; Fri, 15 Nov 2013 10:26:19 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2421F9D53 for ; Fri, 15 Nov 2013 10:26:19 -0800 (PST) Received: from localhost ([127.0.0.1]:43112 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhO5x-0007dk-E4; Fri, 15 Nov 2013 19:26:17 +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: Fri, 15 Nov 2013 18:26:17 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/45 Message-ID: <068.d17c12720f5aa670f4aa8c80255dfee1@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 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: <20131115182619.43E2421F9D53@ietfa.amsl.com> Resent-Date: Fri, 15 Nov 2013 10:26:19 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #45: Clue Protocol: Backwards Compatibility 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: Fri, 15 Nov 2013 18:26:20 -0000 #45: Clue Protocol: Backwards Compatibility Per discussions at IETF-88: http://tools.ietf.org/wg/clue/minutes a decision needs to be made as to whether backwards compatibility is mandatory. -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Fri Nov 15 10:29: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 71A3511E8202 for ; Fri, 15 Nov 2013 10:29:45 -0800 (PST) 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 CFy5Ue38j83c for ; Fri, 15 Nov 2013 10:29:45 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3311E814F for ; Fri, 15 Nov 2013 10:29:44 -0800 (PST) Received: from localhost ([127.0.0.1]:43336 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhO9H-0002j3-LK; Fri, 15 Nov 2013 19:29:43 +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: christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 15 Nov 2013 18:29:43 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/46 Message-ID: <068.45087763dc6bdb8caf94b22a7e431de2@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: 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 Cc: clue@ietf.org Subject: [clue] #46: Data Channel: Single SCTP Connection or Two 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: Fri, 15 Nov 2013 18:29:45 -0000 #46: Data Channel: Single SCTP Connection or Two Per discussion at IETF-88: http://tools.ietf.org/wg/clue/minutes?item=minutes-88-clue.html a decision needs to be made as to whether CLUE will multiplex on a single SCTP connection (using sub-channels) or whether two SCTP connections will be established. It was noted that the latter could limit the potential for CLUE using another transport protocol in the future. This will need to be documented in both the WG signaling document and the WG data channel document. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | christer.holmberg@ericsson.com Type: defect | Status: new Priority: major | Milestone: Component: charter | Version: Severity: Candidate WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Fri Nov 15 10:30: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 31F3621F9FA4 for ; Fri, 15 Nov 2013 10:30:24 -0800 (PST) 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 xuk82hYkzRW6 for ; Fri, 15 Nov 2013 10:30:23 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2520411E814F for ; Fri, 15 Nov 2013 10:30:23 -0800 (PST) Received: from localhost ([127.0.0.1]:43371 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhO9t-0002vE-HL; Fri, 15 Nov 2013 19:30:21 +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: christer.holmberg@ericsson.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 15 Nov 2013 18:30:21 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/46#comment:1 Message-ID: <083.da1d2032142afd91cc18c20b99b9f365@trac.tools.ietf.org> References: <068.45087763dc6bdb8caf94b22a7e431de2@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <068.45087763dc6bdb8caf94b22a7e431de2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: 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 Cc: clue@ietf.org Subject: Re: [clue] #46: Data Channel: Single SCTP Connection or Two 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: Fri, 15 Nov 2013 18:30:24 -0000 #46: Data Channel: Single SCTP Connection or Two Changes (by mary.ietf.barnes@gmail.com): * type: defect => task -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | christer.holmberg@ericsson.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 Fri Nov 15 10:32: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 14CD311E814F for ; Fri, 15 Nov 2013 10:32:03 -0800 (PST) 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 q35zTDJbBgwP for ; Fri, 15 Nov 2013 10:32:02 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 230A021F9F80 for ; Fri, 15 Nov 2013 10:31:44 -0800 (PST) Received: from localhost ([127.0.0.1]:43429 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhOBD-0005x4-4s; Fri, 15 Nov 2013 19:31:43 +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: Fri, 15 Nov 2013 18:31:43 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/45#comment:1 Message-ID: <083.11fae939d30ab7dc2a8dafd0529ac56d@trac.tools.ietf.org> References: <068.d17c12720f5aa670f4aa8c80255dfee1@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <068.d17c12720f5aa670f4aa8c80255dfee1@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] #45: Clue Protocol: Backwards Compatibility 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: Fri, 15 Nov 2013 18:32:03 -0000 #45: Clue Protocol: Backwards Compatibility Changes (by mary.ietf.barnes@gmail.com): * owner: clue-chairs@tools.ietf.org => roberta.presta@unina.it Old description: > Per discussions at IETF-88: http://tools.ietf.org/wg/clue/minutes > a decision needs to be made as to whether backwards compatibility is > mandatory. New description: Per discussions at IETF-88: http://tools.ietf.org/wg/clue/minutes?item=minutes-88-clue.html a decision needs to be made as to whether backwards compatibility is mandatory. -- -- -------------------------------------+------------------------------------- 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 Fri Nov 15 10:33: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 54C3911E8212 for ; Fri, 15 Nov 2013 10:33:43 -0800 (PST) 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 qjpwbR-y6KVu for ; Fri, 15 Nov 2013 10:33:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B718B11E81DF for ; Fri, 15 Nov 2013 10:33:42 -0800 (PST) Received: from localhost ([127.0.0.1]:43665 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VhOD0-0004Vz-Nz; Fri, 15 Nov 2013 19:33:34 +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: Fri, 15 Nov 2013 18:33:34 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/31#comment:1 Message-ID: <083.dabe0c6de3da21f484d2573466c1ec37@trac.tools.ietf.org> References: <068.63e0efe6ab2aba726bfb581e35939a76@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <068.63e0efe6ab2aba726bfb581e35939a76@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: <20131115183342.B718B11E81DF@ietfa.amsl.com> Resent-Date: Fri, 15 Nov 2013 10:33:42 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #31: CLUE state machine 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: Fri, 15 Nov 2013 18:33:43 -0000 #31: CLUE state machine Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue has been resolved as draft-presta-clue-protocol (pending WG approval as a charter item) contains CLUE protocol state machines. -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Resolution: fixed Keywords: Signaling, State | Machine | -------------------------------------+------------------------------------- Ticket URL: clue From pkyzivat@alum.mit.edu Mon Nov 18 10:31:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A298D1A1F42 for ; Mon, 18 Nov 2013 10:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.972 X-Spam-Level: X-Spam-Status: No, score=0.972 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.972] autolearn=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id El0r-MveT0Vj for ; Mon, 18 Nov 2013 10:31:32 -0800 (PST) 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 7B0C11A1F45 for ; Mon, 18 Nov 2013 10:31:29 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id qzzA1m00A1GhbT8536XPVo; Mon, 18 Nov 2013 18:31:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id r6XP1m00H3ZTu2S3T6XPfF; Mon, 18 Nov 2013 18:31:23 +0000 Message-ID: <528A5CFB.7020506@alum.mit.edu> Date: Mon, 18 Nov 2013 10:31:23 -0800 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: "mark.duckworth@polycom.com" , CLUE References: 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=1384799483; bh=fEgr/05Qkv3CYZK8Cwd4WSdvCdvl1c1ig0BUDrcPwPk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o3kFOdJmyppnG+Trn7+Buk5Kwg8wiOlC04BqvUuDGXvEHFSVHg7n8NORsJyuDmzdh R7gcEEnIycDwiUwUFg2LPmsu7FmcmG98zi2rSCx+y6GIKpKSWn3/Wqr9qxVj7la6J+ ycnfqK5sjrYyzJ/y9GZQE2CrAG0/9YsVI+0AgwzAa0mYCskQfiSkM65STABfbHQLzX FWTAAOlRewf4/LC5EnjHWKLoyB0Tq+wvcyn827fhSxGstPmn/AIjxxlt1mUjH35oMj LJMHYKMoVYm8MwsF8vIUTOUBvIq/T8TO6ngd2DM5e/T1ZWVtQXnixs5vtLBz3iMPVl eypZV9GTXESDA== Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2013 18:31:33 -0000 The posted schedule for design team calls skips three Tuesdays due to the winter holidays: Dec 24, Dec 31, Jan 7, and resumes on Jan 14. I was wondering if it is important to people to skip Jan 7. If everybody is ready to work by that date (almost a week after New Year's Day) then we could move the plan up one week. But I don't want to interrupt anyone's holiday plans. Does anyone find Jan 7 a bad day for a design team meeting? (Especially Mark, since he is the one who has the most preparation to do for it.) Thanks, Paul On 11/14/13 3:01 PM, Mary Barnes wrote: > HI all, > > Based on discussions last week, I have posted a proposed schedule for > upcoming design team calls with proposed leads: > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team > > Of course, the order may change based on levels of mailing list > discussions and availability of documents/proposals. So, I suggest that > the lead contact the chairs no later than 8am Central on the Friday > before the DT meeting so we can see if another topic is ready for > discussion. If not, we'll cancel for that week. > > Thanks, > Mary. From Christian.Groves@nteczone.com Mon Nov 18 15:10:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9D31AE6C0 for ; Mon, 18 Nov 2013 15:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.435 X-Spam-Level: *** X-Spam-Status: No, score=3.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q93eyN22acEw for ; Mon, 18 Nov 2013 15:10:19 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373971AE6C5 for ; Mon, 18 Nov 2013 15:10:19 -0800 (PST) Received: from ppp118-209-127-154.lns20.mel4.internode.on.net ([118.209.127.154]:52035 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1ViXux-0003tz-0L for clue@ietf.org; Tue, 19 Nov 2013 10:07:43 +1100 Message-ID: <528A9E52.5040908@nteczone.com> Date: Tue, 19 Nov 2013 10:10:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: clue@ietf.org References: <528A5CFB.7020506@alum.mit.edu> In-Reply-To: <528A5CFB.7020506@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2013 23:10:21 -0000 Hello Paul, The 7th is Orthodox (and Eastern rite) Christmas. Christian On 19/11/2013 5:31 AM, Paul Kyzivat wrote: > The posted schedule for design team calls skips three Tuesdays due to > the winter holidays: Dec 24, Dec 31, Jan 7, and resumes on Jan 14. > > I was wondering if it is important to people to skip Jan 7. If > everybody is ready to work by that date (almost a week after New > Year's Day) then we could move the plan up one week. > > But I don't want to interrupt anyone's holiday plans. > > Does anyone find Jan 7 a bad day for a design team meeting? > (Especially Mark, since he is the one who has the most preparation to > do for it.) > > Thanks, > Paul > > > On 11/14/13 3:01 PM, Mary Barnes wrote: >> HI all, >> >> Based on discussions last week, I have posted a proposed schedule for >> upcoming design team calls with proposed leads: >> http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team >> >> Of course, the order may change based on levels of mailing list >> discussions and availability of documents/proposals. So, I suggest that >> the lead contact the chairs no later than 8am Central on the Friday >> before the DT meeting so we can see if another topic is ready for >> discussion. If not, we'll cancel for that week. >> >> Thanks, >> Mary. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Nov 19 07:22:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003A51AE02A for ; Tue, 19 Nov 2013 07:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoUtNECl3Pao for ; Tue, 19 Nov 2013 07:22:03 -0800 (PST) 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 8C6051AE031 for ; Tue, 19 Nov 2013 07:22:03 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta15.westchester.pa.mail.comcast.net with comcast id rRJq1m0021uE5Es5FTMxFR; Tue, 19 Nov 2013 15:21:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id rTMx1m00N3ZTu2S3cTMxVE; Tue, 19 Nov 2013 15:21:57 +0000 Message-ID: <528B8215.1090008@alum.mit.edu> Date: Tue, 19 Nov 2013 07:21:57 -0800 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@ietf.org References: <528A5CFB.7020506@alum.mit.edu> <528A9E52.5040908@nteczone.com> In-Reply-To: <528A9E52.5040908@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=1384874517; bh=sVkAwFAiMzswAUDS51fllpSWRNLpibrIP0Vyp0YyfeE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ay7f0ta+XUIGxQlX8uJkNboLpg5nB3RLihhQKyZDX0I7/CbW2+q6lg+47pMrv9vrF /CD+3CSoqLDKMCp7/YPvQrT1UBanLjBO9hFRvk8nNRmyDAeZisTvIk4RK0SzfE6/0A aDyfVwZsC8PPn+7QGUeXxby0CRajOSriPg3GsYj1u4BssGzzY1D6BAT+z7smeisdOx pZsE+560dhgokotajB9euuIXv1I/TXIhUyu5U1LBUdBdOVW3jOkvkI5hN321h2wHbM QO9+nbAEzUmMcOJeqaFvzbfHuQ4ZyHM9xOc7qm50wRoULnlceL1P7AOC7Dgd2GikCs cI0ZwK0I1JdgA== Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 19 Nov 2013 15:22:05 -0000 OK. Lets leave things as they are. Thanks, Paul On 11/18/13 3:10 PM, Christian Groves wrote: > Hello Paul, > > The 7th is Orthodox (and Eastern rite) Christmas. > > Christian > > On 19/11/2013 5:31 AM, Paul Kyzivat wrote: >> The posted schedule for design team calls skips three Tuesdays due to >> the winter holidays: Dec 24, Dec 31, Jan 7, and resumes on Jan 14. >> >> I was wondering if it is important to people to skip Jan 7. If >> everybody is ready to work by that date (almost a week after New >> Year's Day) then we could move the plan up one week. >> >> But I don't want to interrupt anyone's holiday plans. >> >> Does anyone find Jan 7 a bad day for a design team meeting? >> (Especially Mark, since he is the one who has the most preparation to >> do for it.) >> >> Thanks, >> Paul >> >> >> On 11/14/13 3:01 PM, Mary Barnes wrote: >>> HI all, >>> >>> Based on discussions last week, I have posted a proposed schedule for >>> upcoming design team calls with proposed leads: >>> http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team >>> >>> Of course, the order may change based on levels of mailing list >>> discussions and availability of documents/proposals. So, I suggest that >>> the lead contact the chairs no later than 8am Central on the Friday >>> before the DT meeting so we can see if another topic is ready for >>> discussion. If not, we'll cancel for that week. >>> >>> Thanks, >>> Mary. >> >> _______________________________________________ >> 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 Thu Nov 21 03:42:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7792D1ADC03 for ; Thu, 21 Nov 2013 03:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qR_QP-V-0wc for ; Thu, 21 Nov 2013 03:42:03 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 729731AD943 for ; Thu, 21 Nov 2013 03:42:03 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id p61so5916796wes.34 for ; Thu, 21 Nov 2013 03:41:56 -0800 (PST) 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:thread-index:content-language; bh=nR/DeEr4/5cqNXtYq2ORmPWqVfKU7KjnvlLdQg5gbcU=; b=po+WY++kSU0Jm68it2m4AsXyLCqE2fgDpz0RsDj9Za098Olde51bVRkWyWZ4pmXbW/ ingWz+MFjdCw8EnDgBTcl07lePCublUrFOrfKrzw/siX/7y3xNxwm3BvM8f59WNPDNZs 5G2qca/aaCufiz6zK2KtPO6IsYdmVNmMfLKPODYAu7ZzlyX7W3iZFFZV7bYfPCMzHi3+ Dp4B625nqYEQYesK0haMgYH2nDNxHzEPcI23rmHmTgeJsMhStuTMmO/9yQqUX9qap47Q GmWVeq57rnVOodHpfxeIvs7zepL79Hld9LcAz6mTQpzM56+4J97pSwuK/K0CAFBpYoOJ rKjA== X-Received: by 10.194.20.202 with SMTP id p10mr5263761wje.39.1385034116347; Thu, 21 Nov 2013 03:41:56 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id bk7sm4648811wib.10.2013.11.21.03.41.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Nov 2013 03:41:55 -0800 (PST) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Thu, 21 Nov 2013 13:38:35 +0200 Message-ID: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A2_01CEE6BE.FC765030" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK1MO/ydIrbp5soZrE0Lcnt70sr7Jhi+f0g Content-Language: en-us Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 11:42:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A2_01CEE6BE.FC765030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, What about framework MCC topic, when is it going to be discussed (January 14th?). Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 15 November, 2013 1:02 AM To: CLUE Subject: [clue] Upcoming Design Team calls HI all, Based on discussions last week, I have posted a proposed schedule for upcoming design team calls with proposed leads: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Of course, the order may change based on levels of mailing list discussions and availability of documents/proposals. So, I suggest that the lead contact the chairs no later than 8am Central on the Friday before the DT meeting so we can see if another topic is ready for discussion. If not, we'll cancel for that week. Thanks, Mary. ------=_NextPart_000_03A2_01CEE6BE.FC765030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

What about framework MCC topic, when is it going to be discussed = (January 14th?).

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 15 November, 2013 1:02 AM
To: = CLUE
Subject: [clue] Upcoming Design Team = calls

 

HI = all,

 

Based on discussions last week, I have posted a = proposed schedule for upcoming design team calls with proposed = leads:

http://= trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

 

Of course, the order may change based on levels of = mailing list discussions and availability of documents/proposals. =  So, I suggest that the lead contact the chairs no later than 8am = Central on the Friday before the DT meeting so we can see if another = topic is ready for discussion. If not, we'll cancel for that = week. 

 

Thanks,

Mary. 

------=_NextPart_000_03A2_01CEE6BE.FC765030-- From dromasca@avaya.com Thu Nov 21 07:08:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF66C1ADFB6; Thu, 21 Nov 2013 07:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPD-HLwVz6iz; Thu, 21 Nov 2013 07:08:30 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4921ADFB5; Thu, 21 Nov 2013 07:08:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkNAGQhjlLGmAcV/2dsb2JhbABZgmYhOFOnZAOUb4EjFm0HgiUBAQEBAgESKDoFBQ0BFQcOFEImAQQODRMHh1kGAQylP5s+jRaCJDGDJ4ESA5lChTmLJ4Mogio X-IronPort-AV: E=Sophos;i="4.93,745,1378872000"; d="scan'208";a="37855525" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Nov 2013 10:08:15 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Nov 2013 10:01:48 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Thu, 21 Nov 2013 16:08:14 +0100 From: "Romascanu, Dan (Dan)" To: "gen-art@ietf.org" Thread-Topic: Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: Ac7my39k5k+95wTYRBa1Lr2SPWE8HQ== Date: Thu, 21 Nov 2013 15:08:13 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 15:08:32 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number = of issues should be clarified before approval.=20 Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wi= kipedia articles (subject to change, subject to attacks) as references, and= I also believe that the current definitions (@11/21/13, US morning hours) = are ambiguous. Actually the Wikipedia article does not include definitions = for Left and Right, and speaks about 'house left' (equal to 'stage right') = and 'house right' (equal to 'stage left'). If another specification in CLUE= will use the terms defined here it is not clear which one is meant.=20 2. In REQMT-1d it is not clear what 'the extent of individual video capture= s' means 3. In REQMT-2d it is not clear what 'the extent of individual audio capture= s' means 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed.=20 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or= extending the specifications for new functionality in the future?=20 Minor issues: 1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is.=20 2. In the Introduction Section I see:=20 > These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is= ambiguous. It would be good to mention (again) in section 5 that by what i= s meant by the 'solution' is the definition of the protocol, not the implem= entation.=20 3. I will defer to the Security Review to comment whether REQMT-18 is enoug= h from a security point of view - especially as the information about media= captures may include explicitly or implicitly details about equipment on e= ach site, etc. To me it seems a little bit too vague.=20 Regards, Dan From mary.ietf.barnes@gmail.com Thu Nov 21 07:56:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BDD1ADFA5 for ; Thu, 21 Nov 2013 07:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJAG9rqjnDBs for ; Thu, 21 Nov 2013 07:56:35 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 42FD11ADFD2 for ; Thu, 21 Nov 2013 07:56:34 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so5169969wes.30 for ; Thu, 21 Nov 2013 07:56:27 -0800 (PST) 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=MY/CRVH8uRtHDpBCM1LLcNz8ntz801TFNhKemvfSU+I=; b=aPbKvtv22qBhUlWmvKPxMkPLJZ3fotPHtgSn5w0f6CgiyY8dhr05HXzZ1hzlz466tP pePpS3HBnSqm0Q1l6ew6SWlD1UIunOnpIIypxeNeRMGJRt0bRk8ZCxzw8OXwlBOC+yVb TSuI9rKTx1aGs6BdXcQhZ+3Jh1tw5eu19Wa7xWEnP4/rUll6WIs/KHVPlM5Aq2ltvdeg fb5w8w4jbnU3nAxRJs7DCYsktJYNmNmvRbZkBZRM6tGYKjHUqsYiKeqfdP0qsD+M+liM eUCCbnAPEpU+QreaYLPPR0uHnkruJWzrDbIQ8PqYoUNAfg2oVsiiQ4lvKcMtd/6uxlse Qb0A== MIME-Version: 1.0 X-Received: by 10.194.20.65 with SMTP id l1mr6146325wje.4.1385049387091; Thu, 21 Nov 2013 07:56:27 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 21 Nov 2013 07:56:26 -0800 (PST) In-Reply-To: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.com> References: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.com> Date: Thu, 21 Nov 2013 09:56:26 -0600 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=047d7b4512a2b6cdaf04ebb1f06f Cc: CLUE Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 15:56:38 -0000 --047d7b4512a2b6cdaf04ebb1f06f Content-Type: text/plain; charset=ISO-8859-1 Jan 14th is the planned target for revisiting any remaining issues on the framework. The specific issues to be discussed are entirely dependent upon issues that arise when the WG reviews the updated document. Perhaps, everyone will be happy with the text being added for MCC and we're done with that in the context of the framework. Mary. On Thu, Nov 21, 2013 at 5:38 AM, Roni Even wrote: > Hi, > > What about framework MCC topic, when is it going to be discussed (January > 14th?). > > > > Roni > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 15 November, 2013 1:02 AM > *To:* CLUE > *Subject:* [clue] Upcoming Design Team calls > > > > HI all, > > > > Based on discussions last week, I have posted a proposed schedule for > upcoming design team calls with proposed leads: > > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team > > > > Of course, the order may change based on levels of mailing list > discussions and availability of documents/proposals. So, I suggest that > the lead contact the chairs no later than 8am Central on the Friday before > the DT meeting so we can see if another topic is ready for discussion. If > not, we'll cancel for that week. > > > > Thanks, > > Mary. > --047d7b4512a2b6cdaf04ebb1f06f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jan 14th is the planned target for revisiting any remainin= g issues on the framework. =A0The specific issues to be discussed are entir= ely dependent upon issues that arise when the WG reviews the updated docume= nt. =A0Perhaps, everyone will be happy with the text being added for MCC an= d we're done with that in the context of the framework.

Mary. =A0=A0

On Thu, Nov 21, 2013 at 5:38 AM, Roni Even = <ron.even.tlv@gmail.com> wrote:

Hi,=

What about framework MCC = topic, when is it going to be discussed (January 14th?). =

=A0<= /p>

Roni

=A0<= /p>

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 15 November, 2013 1:02 AM
To: CLUE
Subject: [clue] Upcoming Design Team calls

=A0

HI all,

=A0

<= /div>

Based on discussions last week, I have pos= ted a proposed schedule for upcoming design team calls with proposed leads:=

=A0

Of course, the order= may change based on levels of mailing list discussions and availability of= documents/proposals. =A0So, I suggest that the lead contact the chairs no = later than 8am Central on the Friday before the DT meeting so we can see if= another topic is ready for discussion. If not, we'll cancel for that w= eek.=A0

=A0

Thanks,

M= ary.=A0


--047d7b4512a2b6cdaf04ebb1f06f-- From pkyzivat@alum.mit.edu Thu Nov 21 08:13:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E056A1ADFF5 for ; Thu, 21 Nov 2013 08:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QouO_U9SUB22 for ; Thu, 21 Nov 2013 08:13:29 -0800 (PST) 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 197C81ADFD2 for ; Thu, 21 Nov 2013 08:13:29 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta15.westchester.pa.mail.comcast.net with comcast id sDGM1m0041vXlb85FGDN9i; Thu, 21 Nov 2013 16:13:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id sGDN1m0053ZTu2S3dGDNUx; Thu, 21 Nov 2013 16:13:22 +0000 Message-ID: <528E3122.2040504@alum.mit.edu> Date: Thu, 21 Nov 2013 08:13:22 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.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=1385050402; bh=0TGMEJtwwWcODMbdyuTl6xH/DK6+3WV5q4uQFV0roVY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ex/Ag2qYDCcLwWCwO01BE1KDXtbJCyCKMze9RIeqXWKQg6ojeGwGJ40U28eiLDJNO 5+EMw7IC50QYZHwNgU3YTZj+/wjJmHh4dBp7NTctvo2Lm+q/bkE3zpWKmne4cRXnNv x6kPGfX4GJUCFicR7FRigiEM23dycWVfltPNMK7Zhx+o22yHf1ncm5XMJ9rCi1yQ4i zh46RVy4FrIRgffw1ur7bvdDy+MVPFt9m/j4ie2kQdbZQK3AsH5Q7kjhlc7P9MhgR/ lEWLNntpRB1cklGBUwHPRtbXXk0ZWzCWnOEfmleK9bqo6l1n2IgTfyTpWU+62Iql8l Gls4axuzrCTfQ== Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 16:13:31 -0000 I agree with Mary on this. Assumption is that the MCC stuff will have been incorporated, and published as part of the next version, and we will be discussing any issues with that. Thanks, Paul On 11/21/13 7:56 AM, Mary Barnes wrote: > Jan 14th is the planned target for revisiting any remaining issues on > the framework. The specific issues to be discussed are entirely > dependent upon issues that arise when the WG reviews the updated > document. Perhaps, everyone will be happy with the text being added for > MCC and we're done with that in the context of the framework. > > Mary. > > > On Thu, Nov 21, 2013 at 5:38 AM, Roni Even > wrote: > > Hi,____ > > What about framework MCC topic, when is it going to be discussed > (January 14^th ?). ____ > > __ __ > > Roni____ > > __ __ > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] *On > Behalf Of *Mary Barnes > *Sent:* 15 November, 2013 1:02 AM > *To:* CLUE > *Subject:* [clue] Upcoming Design Team calls____ > > __ __ > > HI all,____ > > __ __ > > Based on discussions last week, I have posted a proposed schedule > for upcoming design team calls with proposed leads:____ > > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team____ > > __ __ > > Of course, the order may change based on levels of mailing list > discussions and availability of documents/proposals. So, I suggest > that the lead contact the chairs no later than 8am Central on the > Friday before the DT meeting so we can see if another topic is ready > for discussion. If not, we'll cancel for that week. ____ > > __ __ > > Thanks,____ > > Mary. ____ > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Nov 21 08:38:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C5E1AE1D4 for ; Thu, 21 Nov 2013 08:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcUtKoxjdu0p for ; Thu, 21 Nov 2013 08:38:37 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id B02301AE044 for ; Thu, 21 Nov 2013 08:38:37 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta12.westchester.pa.mail.comcast.net with comcast id sF811m0070EZKEL5CGeWt9; Thu, 21 Nov 2013 16:38:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id sGeW1m00Q3ZTu2S3MGeWox; Thu, 21 Nov 2013 16:38:30 +0000 Message-ID: <528E3706.1000102@alum.mit.edu> Date: Thu, 21 Nov 2013 08:38:30 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.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=1385051910; bh=67AsR4wcXt0aoNvNR5neDaOlhhCcBXD8JyG1vc4Iu0w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BX/E273iU+Hsy6OAdcLSHkTaBoapv8TnWhYD51v47NNH/UJJBMGCdhgwoIp++uKs7 g1euMjPcxHvjYLSAbCkM0CDMvsqOdAmB6qC67psQ4s1DOkT5XsFlO0FmDaV8UvepPj z5Ma3GriZN7OYPCE+a4PNG40lk0Guwtv2Xabw+0/rGmtYQgts5TMvB/kJ0jxU8FFtp +a7GXvcDWVc/8NrCpr6bXHD1d/2uCEnzJUYv1tPz0ZuGt5eyvhqYUi1SUBjL8j5mAT O3PVkmNCGEcoC8BNHZZM611aKvlQPIvyYslnsdBkIV+FsQ+B+SAQhztUikd3a7VFpD 9NI05c6Ut4l4g== Cc: "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 16:38:39 -0000 Authors, What do you think of these comments? If you aren't in agreement with all of them, then we should have a dialog with Dan about them. If in agreement, then lets discuss what changes are appropriate. More inline. On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you may receive. > > Document: draft-ietf-clue-telepresence-requirements-06.txt > Reviewer: Dan Romascanu > Review Date: 11/21/13 > IETF LC End Date: 11/27/13 > IESG Telechat date: (if known) > > Summary: It's a good and well written document, almost ready, but a number of issues should be clarified before approval. > > Major issues: > > 1. The definitions of Left and Right in Section 3 use an entry article in Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wikipedia articles (subject to change, subject to attacks) as references, and I also believe that the current definitions (@11/21/13, US morning hours) are ambiguous. Actually the Wikipedia article does not include definitions for Left and Right, and speaks about 'house left' (equal to 'stage right') and 'house right' (equal to 'stage left'). If another specification in CLUE will use the terms defined here it is not clear which one is meant. This seems like a reasonable point to me. Is there a more stable reference we can use? If not, can we just define these terms in the document? > 2. In REQMT-1d it is not clear what 'the extent of individual video captures' means > > 3. In REQMT-2d it is not clear what 'the extent of individual audio captures' means We have had our own concerns about this. I think we want to say *something* but its unclear to me exactly what. Perhaps we could focus on what we want to use this for, and explicitly leave details of what it is for the FW. Thanks, Paul > 4. REQMT-10: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a > telepresence session with those that do. > > More clarity is needed to explain what level of participation in a session (and what limitations) are expected from endpoints that do not support the telepresence extensions. I assume there are limitations, otherwise extensions would not be needed. > > 5. REQMT-15 (last bullet): I could not really figure out what is meant here > > * There can be variation in placement, number and size of > presentations > > 6. REQMT-16: The solution MUST include extensibility mechanisms. > > What 'extensibility' is meant here? Extending the telepresence sessions, or extending the specifications for new functionality in the future? > > > Minor issues: > > 1. If this is the first and basic document to be read by somebody who starts to browse through the CLUE specifications, it would be good to define or expand some place in the introduction what CLUE is. > > 2. In the Introduction Section I see: > >> These > requirements are for the specification, they are not requirements on > the telepresence systems implementing the solution/protocol that will > be specified. > > But then all requirements in section 5 start by 'The solution ...' which is ambiguous. It would be good to mention (again) in section 5 that by what is meant by the 'solution' is the definition of the protocol, not the implementation. > > 3. I will defer to the Security Review to comment whether REQMT-18 is enough from a security point of view - especially as the information about media captures may include explicitly or implicitly details about equipment on each site, etc. To me it seems a little bit too vague. > > Regards, > > Dan > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Nov 21 13:39:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637041AE350 for ; Thu, 21 Nov 2013 13:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O292M1o2S1HS for ; Thu, 21 Nov 2013 13:39:31 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6A1AE34B for ; Thu, 21 Nov 2013 13:39:30 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u56so350987wes.23 for ; Thu, 21 Nov 2013 13:39:23 -0800 (PST) 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=uEqT/dtrgOiaZzhG1Tb+oL9qRjoUbCxHn4D0XDjGSko=; b=q72W8NqoPsiMkNLVtW4+RcMls2GlQJza9m1uSbTrHWQR4wfzQnrbqO61HntTQgzcJV s49S+9GRVGmtvDjz8XHNbVZffgPni6mTWJCJcmJnTTioTTqCK0+0HKGVS29m06vemAJy +8knIIEj84kxkjwaEDh0V/mM1FjEGdt84NzG/2VCp7PWPsaJFLRnFakLzixj6KevoGOm h46EERw2XStxi9vd/opGg3wKX8QmoTg8k6O5d+xjbD1BrQ4nWx+odh2clByKSxY/RYsF q4iNcXUiI6VMpzJVC0UMv/9q2/hOLs++eQ68jp2aM41h0GV+xWEAp2nyRsuLKHENMyAJ Oegg== MIME-Version: 1.0 X-Received: by 10.180.160.212 with SMTP id xm20mr17932595wib.33.1385069963394; Thu, 21 Nov 2013 13:39:23 -0800 (PST) Received: by 10.216.36.4 with HTTP; Thu, 21 Nov 2013 13:39:23 -0800 (PST) In-Reply-To: <528E3706.1000102@alum.mit.edu> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> Date: Thu, 21 Nov 2013 15:39:23 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b624d3428459a04ebb6bb88 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 21 Nov 2013 21:39:34 -0000 --047d7b624d3428459a04ebb6bb88 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat wrote: > Authors, > > What do you think of these comments? > If you aren't in agreement with all of them, then we should have a dialog > with Dan about them. > > If in agreement, then lets discuss what changes are appropriate. > > More inline. > > > On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: > >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> . >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-clue-telepresence-requirements-06.txt >> Reviewer: Dan Romascanu >> Review Date: 11/21/13 >> IETF LC End Date: 11/27/13 >> IESG Telechat date: (if known) >> >> Summary: It's a good and well written document, almost ready, but a >> number of issues should be clarified before approval. >> >> Major issues: >> >> 1. The definitions of Left and Right in Section 3 use an entry article in >> Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of >> Wikipedia articles (subject to change, subject to attacks) as references, >> and I also believe that the current definitions (@11/21/13, US morning >> hours) are ambiguous. Actually the Wikipedia article does not include >> definitions for Left and Right, and speaks about 'house left' (equal to >> 'stage right') and 'house right' (equal to 'stage left'). If another >> specification in CLUE will use the terms defined here it is not clear which >> one is meant. >> > > This seems like a reasonable point to me. Is there a more stable reference > we can use? If not, can we just define these terms in the document? [MB] I'm almost of a mind to just remove those definitions. The consensus was that the terms should be qualified when they are used and the framework does an excellent job of defining more precise terms that properly qualify "left" and "right" and differentiate from stage right, etc. as appropriate. We use "left" and "right" in one place in this requirements document and I think the use is general enough that we don't need a definition (in this document). The wikipedia reference has been in the document since day 1 as a WG document (it was added in -03 of the individual document). The discussions around "left"/"right" on the list were in the context of the definitions document and again, consensus was that the terms should be qualified (as they are in the framework), thus I don't think the current definitions serve any value. [/MB] > > > 2. In REQMT-1d it is not clear what 'the extent of individual video >> captures' means >> >> 3. In REQMT-2d it is not clear what 'the extent of individual audio >> captures' means >> > > We have had our own concerns about this. I think we want to say > *something* but its unclear to me exactly what. Perhaps we could focus on > what we want to use this for, and explicitly leave details of what it is > for the FW. > [MB] Can you point to the threads of discussion where you feel this concern with this phrasing has been raised? There were certainly concerns raised about those requirements (i.e., 3D), but I'm not reading this as Dan's concern. My understanding is that the word "extent" is used in the context of video imagery from the perspective of the camera - i.e., the "angular extent" or something like that. I think we should replace the word "extent" with something more specific. Anyone have a suggestion? And, note these requirements were added based on discussion at IETF-82: http://www.ietf.org/proceedings/82/slides/clue-1.pdf [/MB] > Thanks, > Paul > > > 4. REQMT-10: The solution MUST make it possible for endpoints without >> support for telepresence extensions to participate in a >> telepresence session with those that do. >> >> More clarity is needed to explain what level of participation in a >> session (and what limitations) are expected from endpoints that do not >> support the telepresence extensions. I assume there are limitations, >> otherwise extensions would not be needed. >> >> 5. REQMT-15 (last bullet): I could not really figure out what is meant >> here >> >> * There can be variation in placement, number and size of >> presentations >> >> 6. REQMT-16: The solution MUST include extensibility mechanisms. >> >> What 'extensibility' is meant here? Extending the telepresence sessions, >> or extending the specifications for new functionality in the future? >> >> >> Minor issues: >> >> 1. If this is the first and basic document to be read by somebody who >> starts to browse through the CLUE specifications, it would be good to >> define or expand some place in the introduction what CLUE is. >> >> 2. In the Introduction Section I see: >> >> These >>> >> requirements are for the specification, they are not requirements on >> the telepresence systems implementing the solution/protocol that will >> be specified. >> >> But then all requirements in section 5 start by 'The solution ...' which >> is ambiguous. It would be good to mention (again) in section 5 that by what >> is meant by the 'solution' is the definition of the protocol, not the >> implementation. >> >> 3. I will defer to the Security Review to comment whether REQMT-18 is >> enough from a security point of view - especially as the information about >> media captures may include explicitly or implicitly details about equipment >> on each site, etc. To me it seems a little bit too vague. >> >> Regards, >> >> Dan >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > --047d7b624d3428459a04ebb6bb88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 21, 2013 at 10:38 A= M, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Authors,

What do you think of these comments?
If you aren't in agreement with all of them, then we should have a dial= og with Dan about them.

If in agreement, then lets discuss what changes are appropriate.

More inline.


On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtf= aq>.

Please resolve these comments along with any other Last Call comments you m= ay receive.

Document: draft-ietf-clue-telepresence-requirements-06.txt
Reviewer: Dan Romascanu
Review Date: 11/21/13
IETF LC End Date: 11/27/13
IESG Telechat date: (if known)

Summary: It's a good and well written document, almost ready, but a num= ber of issues should be clarified before approval.

Major issues:

1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usa= ge of Wikipedia articles (subject to change, subject to attacks) as referen= ces, and I also believe that the current definitions (@11/21/13, US morning= hours) are ambiguous. Actually the Wikipedia article does not include defi= nitions for Left and Right, and speaks about 'house left' (equal to= 'stage right') and 'house right' (equal to 'stage left= '). If another specification in CLUE will use the terms defined here it= is not clear which one is meant.

This seems like a reasonable point to me. Is there a more stable reference = we can use? If not, can we just define these terms in the document?
[MB] I'm almost of a mind to just remove those definiti= ons. =A0The consensus was that the terms should be qualified when they are = used and the framework does an excellent job of defining more precise terms= that properly qualify "left" and "right" and different= iate from stage right, etc. as appropriate. =A0We use "left" and = "right" in one place in this requirements document and I think th= e use is general enough that we don't need a definition (in this docume= nt). =A0 The wikipedia reference has been in the document since day 1 as a = WG document (it was added in -03 of the individual document). =A0 The discu= ssions around "left"/"right" on the list were in the co= ntext of the definitions document and again, consensus was that the terms s= hould be qualified (as they are in the framework), thus I don't think t= he current definitions serve any value.=A0[/MB]=A0


2. In REQMT-1d it is not clear what 'the extent of individual video cap= tures' means

3. In REQMT-2d it is not clear what 'the extent of individual audio cap= tures' means

We have had our own concerns about this. I think we want to say *something*= but its unclear to me exactly what. Perhaps we could focus on what we want= to use this for, and explicitly leave details of what it is for the FW.
[MB] Can you point to the threads of discussion whe= re you feel this concern with this phrasing has been raised? =A0 There were= certainly concerns raised about those requirements (i.e., 3D), but I'm= not reading this as Dan's concern. =A0 My understanding is that the wo= rd "extent" is used in the context of video imagery from the pers= pective of the camera - i.e., the "angular extent" or something l= ike that. =A0I think we should replace the word "extent" with som= ething more specific. =A0Anyone have a suggestion?=A0

And, note these requirements were added bas= ed on discussion at IETF-82:
=A0
=A0[/MB]
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


4. REQMT-10: The solution MUST make it possible for endpoints without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support for telepresence extensions to parti= cipate in a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0telepresence session with those that do.

More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed.

5. REQMT-15 (last bullet): I could not really figure out what is meant here=

* =A0There can be variation in placement, number and size of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 presentations

6. REQMT-16: =A0The solution MUST include extensibility mechanisms.

What 'extensibility' is meant here? Extending the telepresence sess= ions, or extending the specifications for new functionality in the future?<= br>

Minor issues:

1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is.

2. In the Introduction Section I see:

=A0 These
=A0 =A0 requirements are for the specification, they are not requirements o= n
=A0 =A0 the telepresence systems implementing the solution/protocol that wi= ll
=A0 =A0 be specified.

But then all requirements in section 5 start by 'The solution ...' = which is ambiguous. It would be good to mention (again) in section 5 that b= y what is meant by the 'solution' is the definition of the protocol= , not the implementation.

3. I will defer to the Security Review to comment whether REQMT-18 is enoug= h from a security point of view - especially as the information about media= captures may include explicitly or implicitly details about equipment on e= ach site, etc. To me it seems a little bit too vague.

Regards,

Dan

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



--047d7b624d3428459a04ebb6bb88-- From ron.even.tlv@gmail.com Fri Nov 22 00:40:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D361A1AE11C for ; Fri, 22 Nov 2013 00:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xMiD9mU0Uir for ; Fri, 22 Nov 2013 00:40:12 -0800 (PST) Received: from mail-ea0-x234.google.com (mail-ea0-x234.google.com [IPv6:2a00:1450:4013:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id A71041AE0FB for ; Fri, 22 Nov 2013 00:40:11 -0800 (PST) Received: by mail-ea0-f180.google.com with SMTP id f15so360204eak.11 for ; Fri, 22 Nov 2013 00:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=C/6Nmfng+uhimLMJEHNDaR6XhJ6LCNHFSKGYc8Khg3A=; b=wc3N6YYurPY6qA1F3qkgtiYSVLkGEglhsvavtK5aky4S3IoLVvp1CcwPMMH02U/Grk llVWaiiaZWRmNLPVBRGUjlFqvGTfD7wU8jFStSuhxZgNBLXGa+hZ3bpZpFRt6AtW4xCb 4LeMZGJYPRHSBv8nA49fBctRGt2Yw/xZhjzIwKAaCLjjtrmNfxGllqK7hHAiqezf4GjB 7H4s+yjr4NJWQrIuuxNKaYE73kI7RiVoxCyclpN+4FyzwXOUzKpj5cfqVHYHK296HbEi 9/rK9iyEZ9NcNgB7PTQGEyDs8pU96wVsAJcoPGktUytyel2FtkXItg0u77DtwwwJYUeZ uaZQ== X-Received: by 10.14.241.76 with SMTP id f52mr944060eer.53.1385109604172; Fri, 22 Nov 2013 00:40:04 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id o1sm19196590eea.10.2013.11.22.00.40.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Nov 2013 00:40:03 -0800 (PST) From: "Roni Even" To: "'Mary Barnes'" References: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.com> In-Reply-To: Date: Fri, 22 Nov 2013 10:36:44 +0200 Message-ID: <055401cee75d$fb5d17c0$f2174740$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0555_01CEE76E.BEE74750" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK1MO/ydIrbp5soZrE0Lcnt70sr7ALC52EWAUxnQh2YQ99QYA== Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 22 Nov 2013 08:40:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0555_01CEE76E.BEE74750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mary, The reason I was asking was because the meeting minutes http://tools.ietf.org/wg/clue/minutes has dates for framework discussion and I am not sure which ones are correct Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 21 November, 2013 5:56 PM To: Roni Even Cc: CLUE Subject: Re: [clue] Upcoming Design Team calls Jan 14th is the planned target for revisiting any remaining issues on the framework. The specific issues to be discussed are entirely dependent upon issues that arise when the WG reviews the updated document. Perhaps, everyone will be happy with the text being added for MCC and we're done with that in the context of the framework. Mary. On Thu, Nov 21, 2013 at 5:38 AM, Roni Even wrote: Hi, What about framework MCC topic, when is it going to be discussed (January 14th?). Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 15 November, 2013 1:02 AM To: CLUE Subject: [clue] Upcoming Design Team calls HI all, Based on discussions last week, I have posted a proposed schedule for upcoming design team calls with proposed leads: http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Of course, the order may change based on levels of mailing list discussions and availability of documents/proposals. So, I suggest that the lead contact the chairs no later than 8am Central on the Friday before the DT meeting so we can see if another topic is ready for discussion. If not, we'll cancel for that week. Thanks, Mary. ------=_NextPart_000_0555_01CEE76E.BEE74750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

The reason I was asking was because the meeting minutes http://tools.ietf.org/wg/c= lue/minutes has dates for framework discussion and I am not sure = which ones are correct

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 21 = November, 2013 5:56 PM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Upcoming Design Team = calls

 

Jan = 14th is the planned target for revisiting any remaining issues on the = framework.  The specific issues to be discussed are entirely = dependent upon issues that arise when the WG reviews the updated = document.  Perhaps, everyone will be happy with the text being = added for MCC and we're done with that in the context of the = framework.

 

Mary.   

 

On Thu, Nov 21, 2013 at 5:38 AM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

What about framework MCC topic, when is it going to be discussed = (January 14th?).

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 15 November, 2013 1:02 AM
To: = CLUE
Subject: [clue] Upcoming Design Team = calls

 <= /o:p>

HI = all,

 <= /o:p>

Based on = discussions last week, I have posted a proposed schedule for upcoming = design team calls with proposed leads:

 <= /o:p>

Of course, = the order may change based on levels of mailing list discussions and = availability of documents/proposals.  So, I suggest that the lead = contact the chairs no later than 8am Central on the Friday before the DT = meeting so we can see if another topic is ready for discussion. If not, = we'll cancel for that week. 

 <= /o:p>

Thanks,=

Mary. <= o:p>

 

------=_NextPart_000_0555_01CEE76E.BEE74750-- From mary.ietf.barnes@gmail.com Fri Nov 22 07:27:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376EE1ADF8F for ; Fri, 22 Nov 2013 07:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcbIRKcR6K81 for ; Fri, 22 Nov 2013 07:26:58 -0800 (PST) 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 737A81ADFD4 for ; Fri, 22 Nov 2013 07:26:58 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so1257487wgh.1 for ; Fri, 22 Nov 2013 07:26:50 -0800 (PST) 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=v0yJMAWhurxWEkxXbDjFQYMLOFDAunJACGoP/aTu5B4=; b=cep3hnaKnbtt033I4nIIqLZnowumq+4c4Jbqq2tHZHkg9IDYj3ZDlxA0wIy0L0Tjp/ sUyCaelVKL5nLApp4edGqWcceiX2Gz4LUnnAy2YhKF2uxqqfvHvbLrtFsItlFU7YNlYX h6YHsgKl+xt/7hz3Tg1d6EVvGnW3XTnqDQKdoAQwiKkSLN0ZpuZThMeFsTqmJiXpXpcu NuaGWvvf2Cg+J/3oCx2k/UCfhqcsqFwYBN9zzAGa3sofN6Yv25cZSR2FuGgMV2r8TDYH snrEXjTnou183eFYCNaF5EXoFPw3ZWqd17yfpIcfMBtCss1FmNnSu/IaYzchNqHvvXDi fPAA== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr10574297wjb.21.1385134010822; Fri, 22 Nov 2013 07:26:50 -0800 (PST) Received: by 10.216.36.4 with HTTP; Fri, 22 Nov 2013 07:26:50 -0800 (PST) In-Reply-To: <055401cee75d$fb5d17c0$f2174740$@gmail.com> References: <03a101cee6ae$38ece3f0$aac6abd0$@gmail.com> <055401cee75d$fb5d17c0$f2174740$@gmail.com> Date: Fri, 22 Nov 2013 09:26:50 -0600 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=089e011779b5ae771d04ebc5a4f4 Cc: CLUE Subject: Re: [clue] Upcoming Design Team calls X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 22 Nov 2013 15:27:01 -0000 --089e011779b5ae771d04ebc5a4f4 Content-Type: text/plain; charset=ISO-8859-1 Okay, now that you point that out, I see the confusion. The date in the minutes for the FW to include switching is an earlier date. The date on the wiki for the DT meeting (for the FW) is based on the latter part of the minutes whereby we have a pre-WGLC and that's to handle any final issues with the framework. So, I missed putting the earlier date in the plans. So, we'll have to adjust things once docs get submitted. At this point, we have nothing new on the table to discuss for next Tuesday, unless Rob or Simon have something new on the encoding limits to be discussed? Mary. On Fri, Nov 22, 2013 at 2:36 AM, Roni Even wrote: > Hi Mary, > > The reason I was asking was because the meeting minutes > http://tools.ietf.org/wg/clue/minutes has dates for framework discussion > and I am not sure which ones are correct > > Roni > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 21 November, 2013 5:56 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Upcoming Design Team calls > > > > Jan 14th is the planned target for revisiting any remaining issues on the > framework. The specific issues to be discussed are entirely dependent upon > issues that arise when the WG reviews the updated document. Perhaps, > everyone will be happy with the text being added for MCC and we're done > with that in the context of the framework. > > > > Mary. > > > > On Thu, Nov 21, 2013 at 5:38 AM, Roni Even wrote: > > Hi, > > What about framework MCC topic, when is it going to be discussed (January > 14th?). > > > > Roni > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 15 November, 2013 1:02 AM > *To:* CLUE > *Subject:* [clue] Upcoming Design Team calls > > > > HI all, > > > > Based on discussions last week, I have posted a proposed schedule for > upcoming design team calls with proposed leads: > > http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team > > > > Of course, the order may change based on levels of mailing list > discussions and availability of documents/proposals. So, I suggest that > the lead contact the chairs no later than 8am Central on the Friday before > the DT meeting so we can see if another topic is ready for discussion. If > not, we'll cancel for that week. > > > > Thanks, > > Mary. > > > --089e011779b5ae771d04ebc5a4f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Okay, now that you point that out, I see the confusion. = =A0The date in the minutes for the FW to include switching is an earlier da= te. The date on the wiki for the DT meeting (for the FW) =A0is based on the= latter part of the minutes whereby we have a pre-WGLC and that's to ha= ndle any final issues with the framework. So, I missed putting the earlier = date in the plans. =A0So, we'll have to adjust things once docs get sub= mitted. =A0

At this point, we have nothing new on the table to discuss f= or next Tuesday, unless Rob or Simon have something new on the encoding lim= its to be discussed? =A0

Mary.=A0



=
On Fri, Nov 22, 2013 at 2:36 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Mary,

The reason I was asking w= as because the meeting minutes http://tools.ietf.org/wg/clue/minutes ha= s dates for framework discussion and I am not sure which ones are correct

Roni=

=A0

From:= Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 21 November, 2013 5:56 PM
To: Roni Even
Cc: CLUE
Subject: Re: [clue] Upcoming Design Team calls

<= /u>=A0

Jan 14th is the planned target for revisiting a= ny remaining issues on the framework. =A0The specific issues to be discusse= d are entirely dependent upon issues that arise when the WG reviews the upd= ated document. =A0Perhaps, everyone will be happy with the text being added= for MCC and we're done with that in the context of the framework.

=A0

Mary. =A0=A0

=A0

On Thu, Nov 21, 2013 at 5:38 AM, Roni Even <ron.even.tlv@gmail.com> wrot= e:

Hi,

What about f= ramework MCC topic, when is it going to be discussed (January 14th?).

=A0<= /p>

Roni<= /u>

=A0<= /p>

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 15 November, 2013 1:02 AM
To: CLUE
Subject: [clue] Upcoming Design Team calls

=A0

HI all,

=A0

<= /div>

Based on discussions last week, I have pos= ted a proposed schedule for upcoming design team calls with proposed leads:=

=A0

Of course, the order= may change based on levels of mailing list discussions and availability of= documents/proposals. =A0So, I suggest that the lead contact the chairs no = later than 8am Central on the Friday before the DT meeting so we can see if= another topic is ready for discussion. If not, we'll cancel for that w= eek.=A0

=A0

Thanks,

M= ary.=A0

=A0


--089e011779b5ae771d04ebc5a4f4-- From pkyzivat@alum.mit.edu Fri Nov 22 10:36:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800971AE039 for ; Fri, 22 Nov 2013 10:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiOJak8KqMP8 for ; Fri, 22 Nov 2013 10:36:12 -0800 (PST) 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 91A431AE009 for ; Fri, 22 Nov 2013 10:36:12 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta01.westchester.pa.mail.comcast.net with comcast id scPt1m0071ap0As51ic5GT; Fri, 22 Nov 2013 18:36:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id sic21m00r3ZTu2S3iic2ye; Fri, 22 Nov 2013 18:36:05 +0000 Message-ID: <528FA412.7000009@alum.mit.edu> Date: Fri, 22 Nov 2013 10:36:02 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@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=1385145365; bh=WOUe+/XTB2aApvvaluMPRE0sz8uMC7GfT4pjgbiARcs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JTUizKl/99OSyes2gPoN6UUJqNAL+rKlmXlUf/WsjxFXtZA2mdhQzUXc7AYkrM0EY zFLUcfXdDq3Zt7QriABzDl+li1FxDddkyKFpyP4uFO0K5qJP7cyjGb+HHtIydM7Erd RQWQuUM4yBw1Xx4NTeImFoHajGHRE2LlpT8reB2ZWt4Gy2lS1Mit1pruaZpuY1tBnq mdq47DQFsTfEkIvvCnlzkJhprMem5hdwpmif+lYPsbWOoHIg42fgYlyGcuatPXTT0N WyRaJrsualDOB6+iQ8eCDl7yS5fK0JdgR52kNINUXnxij1HTeO6ZdyG9/Ask3mSSc8 YDbZ6L5DHMSng== Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 22 Nov 2013 18:36:14 -0000 Inline On 11/21/13 1:39 PM, Mary Barnes wrote: > On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat > wrote: > > Authors, > > What do you think of these comments? > If you aren't in agreement with all of them, then we should have a > dialog with Dan about them. > > If in agreement, then lets discuss what changes are appropriate. > > More inline. > > > On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: > > I am the assigned Gen-ART reviewer for this draft. For > background on Gen-ART, please see the FAQ at > > >. > > Please resolve these comments along with any other Last Call > comments you may receive. > > Document: draft-ietf-clue-telepresence-__requirements-06.txt > Reviewer: Dan Romascanu > Review Date: 11/21/13 > IETF LC End Date: 11/27/13 > IESG Telechat date: (if known) > > Summary: It's a good and well written document, almost ready, > but a number of issues should be clarified before approval. > > Major issues: > > 1. The definitions of Left and Right in Section 3 use an entry > article in Wikipedia ('Stage Directions'). I am both > uncomfortable with the usage of Wikipedia articles (subject to > change, subject to attacks) as references, and I also believe > that the current definitions (@11/21/13, US morning hours) are > ambiguous. Actually the Wikipedia article does not include > definitions for Left and Right, and speaks about 'house left' > (equal to 'stage right') and 'house right' (equal to 'stage > left'). If another specification in CLUE will use the terms > defined here it is not clear which one is meant. > > > This seems like a reasonable point to me. Is there a more stable > reference we can use? If not, can we just define these terms in the > document? > > [MB] I'm almost of a mind to just remove those definitions. The > consensus was that the terms should be qualified when they are used and > the framework does an excellent job of defining more precise terms that > properly qualify "left" and "right" and differentiate from stage right, > etc. as appropriate. We use "left" and "right" in one place in this > requirements document and I think the use is general enough that we > don't need a definition (in this document). The wikipedia reference > has been in the document since day 1 as a WG document (it was added in > -03 of the individual document). The discussions around "left"/"right" > on the list were in the context of the definitions document and again, > consensus was that the terms should be qualified (as they are in the > framework), thus I don't think the current definitions serve any > value. [/MB] WFM. > 2. In REQMT-1d it is not clear what 'the extent of individual > video captures' means > > 3. In REQMT-2d it is not clear what 'the extent of individual > audio captures' means > > > We have had our own concerns about this. I think we want to say > *something* but its unclear to me exactly what. Perhaps we could > focus on what we want to use this for, and explicitly leave details > of what it is for the FW. > > [MB] Can you point to the threads of discussion where you feel this > concern with this phrasing has been raised? There were certainly > concerns raised about those requirements (i.e., 3D), but I'm not reading > this as Dan's concern. My understanding is that the word "extent" is > used in the context of video imagery from the perspective of the camera > - i.e., the "angular extent" or something like that. I think we should > replace the word "extent" with something more specific. Anyone have a > suggestion? I was referring specifically to the comment about *audio*. There was a lot of discussion about the the use of spatial coordinates for this. John Leslie, who seems the most knowledgeable on the subject, has said that they don't mean much. We have talked about other ways of representing this, but I don't know if people have been satisfied with the results or not. Of course most of that is in the FW. Here I think we can be much more vague about what we mean, because it is up to the FW to specify how to accomplish it. That is why I was suggesting that maybe we could just specify what the goal is, with the FW providing the mechanism. I think there are a few goals. The ones that come to mind are: - choosing how to map the capture onto available devices when rendering - deciding how to transform the capture when rendering - correlating audio and video captures Thanks, Paul From ietf-ipr@ietf.org Fri Nov 22 15:26:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00661AE171; Fri, 22 Nov 2013 15:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBka2nyIaaLf; Fri, 22 Nov 2013 15:26:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5D51AE132; Fri, 22 Nov 2013 15:26:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: apeppere@gmail.com,mark.duckworth@polycom.com,stewe@stewe.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122232629.9665.91119.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 15:26:29 -0800 Cc: clue@ietf.org, ipr-announce@ietf.org Subject: [clue] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-clue-framework-12 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 23:26:31 -0000 Dear Andrew Pepperell, Mark Duckworth, Stephan Wenger: An IPR disclosure that pertains to your Internet-Draft entitled "Framework= for Telepresence Multi-Streams" (draft-ietf-clue-framework) was submitted to the IETF Secretariat on 2013-11-22 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2255/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- ietf-clue-framework-12.""); The IETF Secretariat From mary.ietf.barnes@gmail.com Sat Nov 23 12:36:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8747C1AE356 for ; Sat, 23 Nov 2013 12:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW7VccaaZXxL for ; Sat, 23 Nov 2013 12:36:15 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E24861AE353 for ; Sat, 23 Nov 2013 12:36:14 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id p61so2402835wes.20 for ; Sat, 23 Nov 2013 12:36:07 -0800 (PST) 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=/M2p+tFDLgax9XqT8FaRkC7/Wj4yP78fTQhtVySORjQ=; b=Y6fiObibWlLiDIEHDqFFSMrlkAMDpxK9PgjczlUEdQzWDfts2SjAgWo+TMRXn0GDC2 QR46VJIfMYS7aHooRECAhmu4buJEFz8QrpRhEm07WX8Rp8G3NKtG7mlp8nl1/6OEPM92 eYPHxXuiejCoMJhObUX8pNMISunILYd85Fn5Ahu3AzMXfZL7Wmiyb8QtrxTgNcUl+2Hg 8z2DbiBNrxIYzivMTgF/X8e07mqRE8VSKMtVt5dINl/WxHNfCkKy/GGjSFhSeFPiBG8g KL0aWaaJ4LcO6uITMvVBciyjjgDMb3UJJGL+bJQ+DAQpOhNYnomoXAwASdY+1d1afDM0 nZmg== MIME-Version: 1.0 X-Received: by 10.180.73.70 with SMTP id j6mr7568898wiv.47.1385238966988; Sat, 23 Nov 2013 12:36:06 -0800 (PST) Received: by 10.216.36.4 with HTTP; Sat, 23 Nov 2013 12:36:06 -0800 (PST) In-Reply-To: <528FA412.7000009@alum.mit.edu> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <528FA412.7000009@alum.mit.edu> Date: Sat, 23 Nov 2013 14:36:06 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat , "Botzko, Stephen" Content-Type: multipart/alternative; boundary=f46d043890858e765104ebde14ec Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2013 20:36:18 -0000 --f46d043890858e765104ebde14ec Content-Type: text/plain; charset=ISO-8859-1 I chatted with Steve and he has a suggestion for changing that wording that should be acceptable (he also has significant expertise in this area). Steve, can you please post your suggestion to the mailing list? Thanks, Mary. On Fri, Nov 22, 2013 at 12:36 PM, Paul Kyzivat wrote: > Inline > > > On 11/21/13 1:39 PM, Mary Barnes wrote: > >> On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat > > wrote: >> >> Authors, >> >> What do you think of these comments? >> If you aren't in agreement with all of them, then we should have a >> dialog with Dan about them. >> >> If in agreement, then lets discuss what changes are appropriate. >> >> More inline. >> >> >> On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: >> >> I am the assigned Gen-ART reviewer for this draft. For >> background on Gen-ART, please see the FAQ at >> >> > >> >. >> >> Please resolve these comments along with any other Last Call >> comments you may receive. >> >> Document: draft-ietf-clue-telepresence-__requirements-06.txt >> >> Reviewer: Dan Romascanu >> Review Date: 11/21/13 >> IETF LC End Date: 11/27/13 >> IESG Telechat date: (if known) >> >> Summary: It's a good and well written document, almost ready, >> but a number of issues should be clarified before approval. >> >> Major issues: >> >> 1. The definitions of Left and Right in Section 3 use an entry >> article in Wikipedia ('Stage Directions'). I am both >> uncomfortable with the usage of Wikipedia articles (subject to >> change, subject to attacks) as references, and I also believe >> that the current definitions (@11/21/13, US morning hours) are >> ambiguous. Actually the Wikipedia article does not include >> definitions for Left and Right, and speaks about 'house left' >> (equal to 'stage right') and 'house right' (equal to 'stage >> left'). If another specification in CLUE will use the terms >> defined here it is not clear which one is meant. >> >> >> This seems like a reasonable point to me. Is there a more stable >> reference we can use? If not, can we just define these terms in the >> document? >> >> [MB] I'm almost of a mind to just remove those definitions. The >> consensus was that the terms should be qualified when they are used and >> the framework does an excellent job of defining more precise terms that >> properly qualify "left" and "right" and differentiate from stage right, >> etc. as appropriate. We use "left" and "right" in one place in this >> requirements document and I think the use is general enough that we >> don't need a definition (in this document). The wikipedia reference >> has been in the document since day 1 as a WG document (it was added in >> -03 of the individual document). The discussions around "left"/"right" >> on the list were in the context of the definitions document and again, >> consensus was that the terms should be qualified (as they are in the >> framework), thus I don't think the current definitions serve any >> value. [/MB] >> > > WFM. > > > 2. In REQMT-1d it is not clear what 'the extent of individual >> video captures' means >> >> 3. In REQMT-2d it is not clear what 'the extent of individual >> audio captures' means >> >> >> We have had our own concerns about this. I think we want to say >> *something* but its unclear to me exactly what. Perhaps we could >> focus on what we want to use this for, and explicitly leave details >> of what it is for the FW. >> >> [MB] Can you point to the threads of discussion where you feel this >> concern with this phrasing has been raised? There were certainly >> concerns raised about those requirements (i.e., 3D), but I'm not reading >> this as Dan's concern. My understanding is that the word "extent" is >> used in the context of video imagery from the perspective of the camera >> - i.e., the "angular extent" or something like that. I think we should >> replace the word "extent" with something more specific. Anyone have a >> suggestion? >> > > I was referring specifically to the comment about *audio*. > There was a lot of discussion about the the use of spatial coordinates for > this. John Leslie, who seems the most knowledgeable on the subject, has > said that they don't mean much. We have talked about other ways of > representing this, but I don't know if people have been satisfied with the > results or not. > > Of course most of that is in the FW. Here I think we can be much more > vague about what we mean, because it is up to the FW to specify how to > accomplish it. > > That is why I was suggesting that maybe we could just specify what the > goal is, with the FW providing the mechanism. > > I think there are a few goals. The ones that come to mind are: > > - choosing how to map the capture onto available devices when rendering > - deciding how to transform the capture when rendering > - correlating audio and video captures > > Thanks, > Paul > --f46d043890858e765104ebde14ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I chatted with Steve and he has a suggestion for changing = that wording that should be acceptable (he also has significant expertise i= n this area). =A0Steve, can you please post your suggestion to the mailing = list?

Thanks,
Mary.=A0


On Fri, Nov 22, 2013 at 12:36 PM, P= aul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Inline


On 11/21/13 1:39 PM, Mary Barnes wrote:
On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 Authors,

=A0 =A0 What do you think of these comments?
=A0 =A0 If you aren't in agreement with all of them, then we should hav= e a
=A0 =A0 dialog with Dan about them.

=A0 =A0 If in agreement, then lets discuss what changes are appropriate.
=A0 =A0 More inline.


=A0 =A0 On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote:

=A0 =A0 =A0 =A0 I am the assigned Gen-ART reviewer for this draft. For
=A0 =A0 =A0 =A0 background on Gen-ART, please see the FAQ at

=A0 =A0 =A0 =A0 <http://wiki.tools.ietf.org/__area/g= en/trac/wiki/GenArtfaq

=A0 =A0 =A0 =A0 <http://wiki.tools.ietf.org/area/gen/t= rac/wiki/GenArtfaq>>.

=A0 =A0 =A0 =A0 Please resolve these comments along with any other Last Cal= l
=A0 =A0 =A0 =A0 comments you may receive.

=A0 =A0 =A0 =A0 Document: draft-ietf-clue-telepresence-__requirement= s-06.txt

=A0 =A0 =A0 =A0 Reviewer: Dan Romascanu
=A0 =A0 =A0 =A0 Review Date: 11/21/13
=A0 =A0 =A0 =A0 IETF LC End Date: 11/27/13
=A0 =A0 =A0 =A0 IESG Telechat date: (if known)

=A0 =A0 =A0 =A0 Summary: It's a good and well written document, almost = ready,
=A0 =A0 =A0 =A0 but a number of issues should be clarified before approval.=

=A0 =A0 =A0 =A0 Major issues:

=A0 =A0 =A0 =A0 1. The definitions of Left and Right in Section 3 use an en= try
=A0 =A0 =A0 =A0 article in Wikipedia ('Stage Directions'). I am bot= h
=A0 =A0 =A0 =A0 uncomfortable with the usage of Wikipedia articles (subject= to
=A0 =A0 =A0 =A0 change, subject to attacks) as references, and I also belie= ve
=A0 =A0 =A0 =A0 that the current definitions (@11/21/13, US morning hours) = are
=A0 =A0 =A0 =A0 ambiguous. Actually the Wikipedia article does not include<= br> =A0 =A0 =A0 =A0 definitions for Left and Right, and speaks about 'house= left'
=A0 =A0 =A0 =A0 (equal to 'stage right') and 'house right' = (equal to 'stage
=A0 =A0 =A0 =A0 left'). If another specification in CLUE will use the t= erms
=A0 =A0 =A0 =A0 defined here it is not clear which one is meant.


=A0 =A0 This seems like a reasonable point to me. Is there a more stable =A0 =A0 reference we can use? If not, can we just define these terms in the=
=A0 =A0 document?

[MB] I'm almost of a mind to just remove those definitions. =A0The
consensus was that the terms should be qualified when they are used and
the framework does an excellent job of defining more precise terms that
properly qualify "left" and "right" and differentiate f= rom stage right,
etc. as appropriate. =A0We use "left" and "right" in on= e place in this
requirements document and I think the use is general enough that we
don't need a definition (in this document). =A0 The wikipedia reference=
has been in the document since day 1 as a WG document (it was added in
-03 of the individual document). =A0 The discussions around "left"= ;/"right"
on the list were in the context of the definitions document and again,
consensus was that the terms should be qualified (as they are in the
framework), thus I don't think the current definitions serve any
value. [/MB]

WFM.


=A0 =A0 =A0 =A0 2. In REQMT-1d it is not clear what 'the extent of indi= vidual
=A0 =A0 =A0 =A0 video captures' means

=A0 =A0 =A0 =A0 3. In REQMT-2d it is not clear what 'the extent of indi= vidual
=A0 =A0 =A0 =A0 audio captures' means


=A0 =A0 We have had our own concerns about this. I think we want to say
=A0 =A0 *something* but its unclear to me exactly what. Perhaps we could =A0 =A0 focus on what we want to use this for, and explicitly leave details=
=A0 =A0 of what it is for the FW.

[MB] Can you point to the threads of discussion where you feel this
concern with this phrasing has been raised? =A0 There were certainly
concerns raised about those requirements (i.e., 3D), but I'm not readin= g
this as Dan's concern. =A0 My understanding is that the word "exte= nt" is
used in the context of video imagery from the perspective of the camera
- i.e., the "angular extent" or something like that. =A0I think w= e should
replace the word "extent" with something more specific. =A0Anyone= have a
suggestion?

I was referring specifically to the comment about *audio*.
There was a lot of discussion about the the use of spatial coordinates for = this. John Leslie, who seems the most knowledgeable on the subject, has sai= d that they don't mean much. We have talked about other ways of represe= nting this, but I don't know if people have been satisfied with the res= ults or not.

Of course most of that is in the FW. Here I think we can be much more vague= about what we mean, because it is up to the FW to specify how to accomplis= h it.

That is why I was suggesting that maybe we could just specify what the goal= is, with the FW providing the mechanism.

I think there are a few goals. The ones that come to mind are:

- choosing how to map the capture onto available devices when rendering
- deciding how to transform the capture when rendering
- correlating audio and video captures

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

--f46d043890858e765104ebde14ec-- From Christian.Groves@nteczone.com Sun Nov 24 17:20:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FE1AE372 for ; Sun, 24 Nov 2013 17:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.435 X-Spam-Level: *** X-Spam-Status: No, score=3.435 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.982] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YN1-BnS_nzCC for ; Sun, 24 Nov 2013 17:20:25 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFB71AE35E for ; Sun, 24 Nov 2013 17:20:24 -0800 (PST) Received: from ppp118-209-29-123.lns20.mel4.internode.on.net ([118.209.29.123]:55455 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Vkkpa-0002NK-6T for clue@ietf.org; Mon, 25 Nov 2013 12:19:18 +1100 Message-ID: <5292A5CE.4050605@nteczone.com> Date: Mon, 25 Nov 2013 12:20:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2013 01:20:27 -0000 Hello all, I'd like to pick up the discussion on roles from the last CLUE WG meeting and try and make some progress via email before the design team meeting. First i'd like to clarify that "role" is not intended to be a single attribute and it can have different meanings. My draft (draft-groves-clue-role-clarifications-00) seeks to clarify and provide a terminology to be more specific. I.e.: 2.1. Meeting Roles 2.2. Conference System Control Roles 2.3. Institution type 2.4. Person Name Title 2.5. Person Occupation (Job Title) 2.6. Organisation Name 2.7. Meeting Specific Roles Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. 2.1 and 2.7 have also been grouped by the draft. There has been some concern that "roles" overlap with floor control. From the role categories above I believe this is only relevant for "conference system control" roles. Secondly the intended purpose of including "roles" into CLUE is not for conference control or rostering but is for the selection of Scenes/Captures and may be used for any subsequent rendering decisions like the other CLUE attributes. The focus of the CLUE work has been to focus on selecting captures based on technical aspects (what) e.g. spatial properties but I think we've missed a more important aspect that captures will depict people or entities (who). As a consumer I'm likely to be more interested in who rather than what. For example if I have a limited system and have received an Advertisement advertising 3 Captures(left/centre/right) and I have only one screen so must choose one. One could choose the centre but this is a problem if my boss is sitting in the left capture. Thirdly because CLUE enhances the support of multiple streams there is likely to be a larger set of captures being advertised. Information about sources scenes/captures including different combinations may be sent to a consumer providing much more choice. Each of these scenes/captures may have different role information. Rather than try to implement role across several different methods and introduce dependencies between CLUE and other methods (e.g. conference package or SDP which have no Scene/capture/MCC concepts) it is most straightforward to send the information where it is needed i.e. in CLUE. Fourthly we have included the "description" parameter at the Scene,CSE and Capture level. I think people will use those as de-facto for "role" type information e.g. Scene Description="Company X VIC meeting room". Rather than have a completely unstructured usage of description I think that having "role" type information provided in a structured form (i.e. via vCard) will at least provide a consumer the ability to do some intelligent processing/rendering of the information. By allowing this "role" information to be sent in a structured way via CLUE I think will be an enabler for some interesting services and features. Finally to re-iterate what the proposal is from the draft: 1. The addition of a capture attribute "Meeting Role" attribute with values as per section 3.1 and 3.2. 2. The addition of a capture attribute "Conference System Control Role" attribute with values as per section 3.3. 3. The addition of a capture attribute "vCard" that allows one or more vCards according to [RFC6350] to be associated with a capture. 4. The addition of a capture attribute "End point vCard" that allows a "group", "org" or "location" kind of vCard according to section 6.1.4/[RFC6350] to be associated with a capture. Comments? Regards, Christian From ron.even.tlv@gmail.com Mon Nov 25 05:09:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504541AD694 for ; Mon, 25 Nov 2013 05:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29IsLIlY8EMy for ; Mon, 25 Nov 2013 05:09:37 -0800 (PST) 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 BEC761ACCE3 for ; Mon, 25 Nov 2013 05:09:36 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id ca18so5412354wib.11 for ; Mon, 25 Nov 2013 05:09:36 -0800 (PST) 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=Dvbpdp9Er5PHBje8eC/l/lmQDGDPm6aS+C371hxcK/g=; b=PGQ4/bpYWZrTcyDgiLvURiwhg8feX3PsScQ5YO5VPrNhZJv+t1wACGMplMLgU+agf1 nV+0ixtTGE6fvDfb6Bes4/zil3nKR/lsmUcEbNabqR3wxSVRfvh3CqyvC1ZQgk7Pc7xS 85/rRbyinXMIDhvOU7xFaW7UUcUMXmraGSeWgb3hfZbazOvMOZMU1ll2/4btyxPCN/MS ThP4hx9mTa2gz8ODNMOfXykUc5fZrO/pIEXCa0SvMWPItOuSy5lUrfSV7Dz3tT0tEPVv UwGIBEXs88Nx8XyHl1tMlyl6WfdrsJKT1QzoEYAx5v4VrWF5J9IrECNctSd4OljKENW8 MaBQ== X-Received: by 10.180.185.201 with SMTP id fe9mr13565228wic.63.1385384976518; Mon, 25 Nov 2013 05:09:36 -0800 (PST) Received: from RoniE ([109.67.11.64]) by mx.google.com with ESMTPSA id dn2sm49659551wid.1.2013.11.25.05.09.34 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Nov 2013 05:09:35 -0800 (PST) From: "Roni Even" To: "'Christian Groves'" , References: <5292A5CE.4050605@nteczone.com> In-Reply-To: <5292A5CE.4050605@nteczone.com> Date: Mon, 25 Nov 2013 15:06:15 +0200 Message-ID: <0b5001cee9df$2193db80$64bb9280$@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: AQF3xLmwFDULsUa4e1u81hGIi5AiYJrkM2eA Content-Language: en-us Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2013 13:09:39 -0000 Hi Cristian, A clarification question about the usage. I think that you are saying that there is an application usage where a person provides his Vcard information to the system, for example, by swiping his Company ID, and this information is provided via CLUE to be displayed by the application on the other side of the call. Are there other use cases or application flows that you see that will explain the application use and flow? Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 25 November, 2013 3:20 AM > To: clue@ietf.org > Subject: [clue] Roles > > Hello all, > > I'd like to pick up the discussion on roles from the last CLUE WG meeting and > try and make some progress via email before the design team meeting. > > First i'd like to clarify that "role" is not intended to be a single attribute and it > can have different meanings. My draft > (draft-groves-clue-role-clarifications-00) seeks to clarify and provide a > terminology to be more specific. I.e.: > 2.1. Meeting Roles > 2.2. Conference System Control Roles > 2.3. Institution type > 2.4. Person Name Title > 2.5. Person Occupation (Job Title) > 2.6. Organisation Name > 2.7. Meeting Specific Roles > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. > 2.1 and 2.7 have also been grouped by the draft. > > There has been some concern that "roles" overlap with floor control. > From the role categories above I believe this is only relevant for "conference > system control" roles. > > Secondly the intended purpose of including "roles" into CLUE is not for > conference control or rostering but is for the selection of Scenes/Captures and > may be used for any subsequent rendering decisions like the other CLUE > attributes. The focus of the CLUE work has been to focus on selecting captures > based on technical aspects (what) e.g. > spatial properties but I think we've missed a more important aspect that > captures will depict people or entities (who). As a consumer I'm likely to be > more interested in who rather than what. For example if I have a limited > system and have received an Advertisement advertising 3 > Captures(left/centre/right) and I have only one screen so must choose one. One > could choose the centre but this is a problem if my boss is sitting in the left > capture. > > Thirdly because CLUE enhances the support of multiple streams there is likely > to be a larger set of captures being advertised. Information about sources > scenes/captures including different combinations may be sent to a consumer > providing much more choice. Each of these scenes/captures may have different > role information. Rather than try to implement role across several different > methods and introduce dependencies between CLUE and other methods (e.g. > conference package or SDP which have no Scene/capture/MCC concepts) it is > most straightforward to send the information where it is needed i.e. in CLUE. > > Fourthly we have included the "description" parameter at the Scene,CSE and > Capture level. I think people will use those as de-facto for "role" > type information e.g. Scene Description="Company X VIC meeting room". > Rather than have a completely unstructured usage of description I think that > having "role" type information provided in a structured form (i.e. > via vCard) will at least provide a consumer the ability to do some intelligent > processing/rendering of the information. By allowing this "role" information to > be sent in a structured way via CLUE I think will be an enabler for some > interesting services and features. > > Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. > > Comments? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From michael.hammer@yaanatech.com Mon Nov 25 06:18:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C420C1AD8F1 for ; Mon, 25 Nov 2013 06:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy8UtV28pIpO for ; Mon, 25 Nov 2013 06:18:41 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 74D361AD72A for ; Mon, 25 Nov 2013 06:18:41 -0800 (PST) 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; Mon, 25 Nov 2013 06:18:41 -0800 From: Michael Hammer To: "ron.even.tlv@gmail.com" , "Christian.Groves@nteczone.com" , "clue@ietf.org" Thread-Topic: [clue] Roles Thread-Index: AQHO6XyDoz4IP0c9LUeTUk2PvJY9X5o2cWGA//+MyJA= Date: Mon, 25 Nov 2013 14:18:41 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> In-Reply-To: <0b5001cee9df$2193db80$64bb9280$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.241] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01CEE9BF.545BA2C0" MIME-Version: 1.0 Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2013 14:18:44 -0000 ------=_NextPart_000_000D_01CEE9BF.545BA2C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christian, I didn't see something here, but perhaps it is stated elsewhere. If you include an element in a protocol, it is usually good to say what the recipient does with it. Is the role something that will change the automated or manual behavior of the receiving system? Or, is it just for display? Also, if some of the roles affect different functions than other roles, you may be building confusion into the protocol. Might be good to spell that out. Mike -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, November 25, 2013 8:06 AM To: 'Christian Groves'; clue@ietf.org Subject: Re: [clue] Roles Hi Cristian, A clarification question about the usage. I think that you are saying that there is an application usage where a person provides his Vcard information to the system, for example, by swiping his Company ID, and this information is provided via CLUE to be displayed by the application on the other side of the call. Are there other use cases or application flows that you see that will explain the application use and flow? Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > Groves > Sent: 25 November, 2013 3:20 AM > To: clue@ietf.org > Subject: [clue] Roles > > Hello all, > > I'd like to pick up the discussion on roles from the last CLUE WG > meeting and > try and make some progress via email before the design team meeting. > > First i'd like to clarify that "role" is not intended to be a single attribute and it > can have different meanings. My draft > (draft-groves-clue-role-clarifications-00) seeks to clarify and > provide a terminology to be more specific. I.e.: > 2.1. Meeting Roles > 2.2. Conference System Control Roles > 2.3. Institution type > 2.4. Person Name Title > 2.5. Person Occupation (Job Title) > 2.6. Organisation Name > 2.7. Meeting Specific Roles > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. > 2.1 and 2.7 have also been grouped by the draft. > > There has been some concern that "roles" overlap with floor control. > From the role categories above I believe this is only relevant for "conference > system control" roles. > > Secondly the intended purpose of including "roles" into CLUE is not > for conference control or rostering but is for the selection of Scenes/Captures and > may be used for any subsequent rendering decisions like the other CLUE > attributes. The focus of the CLUE work has been to focus on selecting captures > based on technical aspects (what) e.g. > spatial properties but I think we've missed a more important aspect > that captures will depict people or entities (who). As a consumer I'm > likely to be > more interested in who rather than what. For example if I have a > limited system and have received an Advertisement advertising 3 > Captures(left/centre/right) and I have only one screen so must choose one. One > could choose the centre but this is a problem if my boss is sitting in > the left > capture. > > Thirdly because CLUE enhances the support of multiple streams there is likely > to be a larger set of captures being advertised. Information about > sources scenes/captures including different combinations may be sent > to a consumer providing much more choice. Each of these > scenes/captures may have different > role information. Rather than try to implement role across several different > methods and introduce dependencies between CLUE and other methods (e.g. > conference package or SDP which have no Scene/capture/MCC concepts) it > is most straightforward to send the information where it is needed > i.e. in CLUE. > > Fourthly we have included the "description" parameter at the Scene,CSE > and Capture level. I think people will use those as de-facto for "role" > type information e.g. Scene Description="Company X VIC meeting room". > Rather than have a completely unstructured usage of description I > think that > having "role" type information provided in a structured form (i.e. > via vCard) will at least provide a consumer the ability to do some intelligent > processing/rendering of the information. By allowing this "role" information to > be sent in a structured way via CLUE I think will be an enabler for > some interesting services and features. > > Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. > > Comments? > > 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 ------=_NextPart_000_000D_01CEE9BF.545BA2C0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEy NTE0MTg0MFowIwYJKoZIhvcNAQkEMRYEFJyHtiYwuVNz+MFvT5sRreA0wkQiMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEARQ045V4HQ8vtZ7AwiSPHf4tLpvA/JO4shGCkhc04 8T2ibJowcpECOpWzumVORsJCDQG/FHW8TruoktFni2SJYGZwK5lyhp+BWvEfS4M+TPM44wOb/uMO PbiGA0jBXBtbhcklmfWkO1UXB4LmRLCczQ3jgMSyQgQ3Il1QryjyDTLAyhfh6D3YplxqeM9I7J1n vNRN9m4PxKF+ZTANVhY9NWDY7J1Ox2FdwyIGSQDxN9M8xgUrfRRFNqGoP3gH6QttRgBnn9Q8qJXN ueXpDgZEmQqGjxOK5VN7qfxC/G5zaMPURGiRf77nE8pWt5xz1UVM11EHYGdEEEbwPtGDKNYm8QAA AAAAAA== ------=_NextPart_000_000D_01CEE9BF.545BA2C0-- From Christian.Groves@nteczone.com Mon Nov 25 18:02:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8841AE0E1 for ; Mon, 25 Nov 2013 18:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.265 X-Spam-Level: X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_INVITATION=-2, RDNS_DYNAMIC=0.982] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-Hba4s1g3dw for ; Mon, 25 Nov 2013 18:02:36 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E7A1AE0BC for ; Mon, 25 Nov 2013 18:02:35 -0800 (PST) Received: from ppp118-209-124-146.lns20.mel4.internode.on.net ([118.209.124.146]:55718 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Vl7xo-0007Md-0q; Tue, 26 Nov 2013 13:01:20 +1100 Message-ID: <52940134.7090301@nteczone.com> Date: Tue, 26 Nov 2013 13:02:28 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Hammer , "ron.even.tlv@gmail.com" , "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2013 02:02:39 -0000 Hello Mike and Roni, In terms of usage I can see several different scenarios. An advertiser ------------- The "role" information could be pre-configured into an endpoint. E.g. a vCard with group/organisation/location could be pre-configured so that each time the endpoint makes a call this information is provided as a description of the scene that is advertised. Likewise a vCard could be pre-configured for certain captures. E.g. if you have a home based video conferencing facility then you can have vCard with personal information (name, etc.) that would sent each time you advertise a capture. This may be helpful for a multi-point scenario for consumers to identify your capture. Then there are cases where there is more dynamic setting of "role" to scenes/captures. As Roni alluded to below there are systems where it is possible to insert an ID card at each seating position that would allow a system to identify people within a capture. I can see that with Smartphones with NFC that it will be possible to get vCard style information from user's phones. It should also be possible to have some integration with the conference reservation/invitation system whereby people can select where they are sitting based on a GUI. Likewise persons could indicate their meeting role. I.e. that they are the meeting chair, secretary etc. This information is then transmitted in a CLUE Advertisement. There is also a consideration of "roles" moving between captures. E.g. a person moves between capture regions. I think in most cases people are generally fairly static within a capture. In more "dynamic" cases how the "role" mapped to capture would be dependent on how it was determined in the first place. e.g. if someone gets up and moves between captures but leaves their ID card in the place they were sitting then the system wouldn't track the movement. Whereas if they swapped a seating position and swapped the ID card then the endpoint could issue an Advertisement with the updated information. If people are wandering back and forth between captures in a scene then the information may be better placed at a scene level. There will be corner cases where the role information won't be valid. I think this is more of an application issue rather than a CLUE issue. A consumer ---------- As indicated below the received role information may be used for capture selection and rendering purposes. This information could be used in many ways depending on the system/application scenario. For a symmetric point to point session the "role" information (as some other CLUE attributes) is not likely to be used for capture selection as there would be no reason to do so. However the information could be used by the consumer for display to the users. How the information is displayed would be dependent on the GUI. e.g. In one system the vCard information of the scene description could be overlayed in a corner of the video. In another system this could be made available via a menu on the video display. In other systems this could be on a separate control monitor. Having this information available for the users I think is a benefit because being able to identify the people participating adds to the being there experience particularly as CLUE is providing information about multiple streams from an endpoint. Quite often I've been in meetings wondering who the person was and where they are from... Asymmetric point to point cases is where the "role" information can be used to select scenes/captures particularly if the consumer has less capability. This selection of captures could be automatic (based on prior provisioning) or manual. For example I as a user may have a regular conference with my manager and several colleagues (three screen/camera endpoint), but I only have 1 screen. I might set a prior policy to select captures where my manager is located (he never sits in the same seat). Likewise I could set a policy to always select a capture with the meeting chairman. An alternative could be to present a list of captures and associated information at call setup so that a user could choose. A third option is to setup a default session and then a user could choose the captures (via a GUI) and do a re-configure. The key is that a user has more information about the contents of the captures. There may be additional captures that aren't currently rendered so they can't rely solely on visual or audio data. For multi-point conferences is where I see roles being very useful. Due to the number of scenes/captures from diverse sources I think it more important to be able to provide information about the source scenes and captures. For example if the source scenes/captures are Advertised via an MCC and the consumer has a limited ability to render them all then it could use either the vCard information associated with the scene (i.e. select a particular location) or vCard information associated with captures (i.e. select captures representing people the consumer feels are important) or the consumer could select scenes/captures with people important to the meeting (i.e. chairman/scribe/etc). As discussed above this could be done dynamically or via information presented to a consumer. A consumer can then send a configure selecting the required Scenes/Captures/Inputs to a MCC. In the case where the information is presented/rendered to a consumer where there are large numbers of potential scenes/captures its important to give some meaning to the captures beyond Capture1, Capture2, Capture3 etc. so that a user can make a choice. That way a user can choose a capture even if it is not currently being rendered. As mentioned above the role information can also be used for rendering. Larger conferences it becomes harder to keep track of people. The role information could also be presented in other ways, e.g. a list of people who participated. In general I don't think there is any mandatory behaviour on receipt of "role" information. Like the other CLUE attributes the receiver may use the information for capture selection and rendering purposes. I think CLUE is different from other protocols where if you send element X you expect that the receiver does behaviour Y (i.e. tightly coupled). I think CLUE is more liberal in that a Advertiser sends information but the consumer doesn't actually have to use it all. Regards, Christian On 26/11/2013 1:18 AM, Michael Hammer wrote: > Christian, > > I didn't see something here, but perhaps it is stated elsewhere. > If you include an element in a protocol, it is usually good to say what the > recipient does with it. > Is the role something that will change the automated or manual behavior of > the receiving system? > Or, is it just for display? > > Also, if some of the roles affect different functions than other roles, > you may be building confusion into the protocol. > Might be good to spell that out. > > Mike > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Monday, November 25, 2013 8:06 AM > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] Roles > > Hi Cristian, > A clarification question about the usage. > I think that you are saying that there is an application usage where a > person provides his Vcard information to the system, for example, by swiping > his Company ID, and this information is provided via CLUE to be displayed by > the application on the other side of the call. > Are there other use cases or application flows that you see that will > explain the application use and flow? > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: 25 November, 2013 3:20 AM >> To: clue@ietf.org >> Subject: [clue] Roles >> >> Hello all, >> >> I'd like to pick up the discussion on roles from the last CLUE WG >> meeting > and >> try and make some progress via email before the design team meeting. >> >> First i'd like to clarify that "role" is not intended to be a single > attribute and it >> can have different meanings. My draft >> (draft-groves-clue-role-clarifications-00) seeks to clarify and >> provide a terminology to be more specific. I.e.: >> 2.1. Meeting Roles >> 2.2. Conference System Control Roles >> 2.3. Institution type >> 2.4. Person Name Title >> 2.5. Person Occupation (Job Title) >> 2.6. Organisation Name >> 2.7. Meeting Specific Roles >> >> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. >> 2.1 and 2.7 have also been grouped by the draft. >> >> There has been some concern that "roles" overlap with floor control. >> From the role categories above I believe this is only relevant for > "conference >> system control" roles. >> >> Secondly the intended purpose of including "roles" into CLUE is not >> for conference control or rostering but is for the selection of > Scenes/Captures and >> may be used for any subsequent rendering decisions like the other CLUE >> attributes. The focus of the CLUE work has been to focus on selecting > captures >> based on technical aspects (what) e.g. >> spatial properties but I think we've missed a more important aspect >> that captures will depict people or entities (who). As a consumer I'm >> likely to > be >> more interested in who rather than what. For example if I have a >> limited system and have received an Advertisement advertising 3 >> Captures(left/centre/right) and I have only one screen so must choose one. > One >> could choose the centre but this is a problem if my boss is sitting in >> the > left >> capture. >> >> Thirdly because CLUE enhances the support of multiple streams there is > likely >> to be a larger set of captures being advertised. Information about >> sources scenes/captures including different combinations may be sent >> to a consumer providing much more choice. Each of these >> scenes/captures may have > different >> role information. Rather than try to implement role across several > different >> methods and introduce dependencies between CLUE and other methods (e.g. >> conference package or SDP which have no Scene/capture/MCC concepts) it >> is most straightforward to send the information where it is needed >> i.e. in > CLUE. >> Fourthly we have included the "description" parameter at the Scene,CSE >> and Capture level. I think people will use those as de-facto for "role" >> type information e.g. Scene Description="Company X VIC meeting room". >> Rather than have a completely unstructured usage of description I >> think > that >> having "role" type information provided in a structured form (i.e. >> via vCard) will at least provide a consumer the ability to do some > intelligent >> processing/rendering of the information. By allowing this "role" > information to >> be sent in a structured way via CLUE I think will be an enabler for >> some interesting services and features. >> >> Finally to re-iterate what the proposal is from the draft: >> 1. The addition of a capture attribute "Meeting Role" attribute >> with values as per section 3.1 and 3.2. >> 2. The addition of a capture attribute "Conference System >> Control Role" attribute with values as per section 3.3. >> 3. The addition of a capture attribute "vCard" that allows one >> or more vCards according to [RFC6350] to be associated with a >> capture. >> 4. The addition of a capture attribute "End point vCard" that >> allows a "group", "org" or "location" kind of vCard according >> to section 6.1.4/[RFC6350] to be associated with a capture. >> >> Comments? >> >> 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 michael.hammer@yaanatech.com Mon Nov 25 18:17:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737941AE11F for ; Mon, 25 Nov 2013 18:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyIRohJx9cPO for ; Mon, 25 Nov 2013 18:17:38 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D31ABD2A for ; Mon, 25 Nov 2013 18:17:38 -0800 (PST) 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; Mon, 25 Nov 2013 18:17:38 -0800 From: Michael Hammer To: "Christian.Groves@nteczone.com" , "ron.even.tlv@gmail.com" , "clue@ietf.org" Thread-Topic: [clue] Roles Thread-Index: AQHO6XyDoz4IP0c9LUeTUk2PvJY9X5o2cWGA//+MyJCAAUwXAP//fCwg Date: Tue, 26 Nov 2013 02:17:37 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> In-Reply-To: <52940134.7090301@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.241] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0349_01CEEA23.C3595690" MIME-Version: 1.0 Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2013 02:17:43 -0000 ------=_NextPart_000_0349_01CEEA23.C3595690 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Christian, Appreciate the response, but there is a lot of "hand-waving" going on here. Could you distill this down more? If a "role" value is received by the endpoint, can that role value by itself be used to make a request into the system to request a change to the media feeds from the MCC? If not, does the role value need to be associated with some other concurrent value and fed back to the MCC to do some type of selection? Does the role value provided only allow local control, and not control over the network-based feeds? Also, do *all* role values enable changes to the network traffic? Thanks, Mike -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: Monday, November 25, 2013 9:02 PM To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org Subject: Re: [clue] Roles Hello Mike and Roni, In terms of usage I can see several different scenarios. An advertiser ------------- The "role" information could be pre-configured into an endpoint. E.g. a vCard with group/organisation/location could be pre-configured so that each time the endpoint makes a call this information is provided as a description of the scene that is advertised. Likewise a vCard could be pre-configured for certain captures. E.g. if you have a home based video conferencing facility then you can have vCard with personal information (name, etc.) that would sent each time you advertise a capture. This may be helpful for a multi-point scenario for consumers to identify your capture. Then there are cases where there is more dynamic setting of "role" to scenes/captures. As Roni alluded to below there are systems where it is possible to insert an ID card at each seating position that would allow a system to identify people within a capture. I can see that with Smartphones with NFC that it will be possible to get vCard style information from user's phones. It should also be possible to have some integration with the conference reservation/invitation system whereby people can select where they are sitting based on a GUI. Likewise persons could indicate their meeting role. I.e. that they are the meeting chair, secretary etc. This information is then transmitted in a CLUE Advertisement. There is also a consideration of "roles" moving between captures. E.g. a person moves between capture regions. I think in most cases people are generally fairly static within a capture. In more "dynamic" cases how the "role" mapped to capture would be dependent on how it was determined in the first place. e.g. if someone gets up and moves between captures but leaves their ID card in the place they were sitting then the system wouldn't track the movement. Whereas if they swapped a seating position and swapped the ID card then the endpoint could issue an Advertisement with the updated information. If people are wandering back and forth between captures in a scene then the information may be better placed at a scene level. There will be corner cases where the role information won't be valid. I think this is more of an application issue rather than a CLUE issue. A consumer ---------- As indicated below the received role information may be used for capture selection and rendering purposes. This information could be used in many ways depending on the system/application scenario. For a symmetric point to point session the "role" information (as some other CLUE attributes) is not likely to be used for capture selection as there would be no reason to do so. However the information could be used by the consumer for display to the users. How the information is displayed would be dependent on the GUI. e.g. In one system the vCard information of the scene description could be overlayed in a corner of the video. In another system this could be made available via a menu on the video display. In other systems this could be on a separate control monitor. Having this information available for the users I think is a benefit because being able to identify the people participating adds to the being there experience particularly as CLUE is providing information about multiple streams from an endpoint. Quite often I've been in meetings wondering who the person was and where they are from... Asymmetric point to point cases is where the "role" information can be used to select scenes/captures particularly if the consumer has less capability. This selection of captures could be automatic (based on prior provisioning) or manual. For example I as a user may have a regular conference with my manager and several colleagues (three screen/camera endpoint), but I only have 1 screen. I might set a prior policy to select captures where my manager is located (he never sits in the same seat). Likewise I could set a policy to always select a capture with the meeting chairman. An alternative could be to present a list of captures and associated information at call setup so that a user could choose. A third option is to setup a default session and then a user could choose the captures (via a GUI) and do a re-configure. The key is that a user has more information about the contents of the captures. There may be additional captures that aren't currently rendered so they can't rely solely on visual or audio data. For multi-point conferences is where I see roles being very useful. Due to the number of scenes/captures from diverse sources I think it more important to be able to provide information about the source scenes and captures. For example if the source scenes/captures are Advertised via an MCC and the consumer has a limited ability to render them all then it could use either the vCard information associated with the scene (i.e. select a particular location) or vCard information associated with captures (i.e. select captures representing people the consumer feels are important) or the consumer could select scenes/captures with people important to the meeting (i.e. chairman/scribe/etc). As discussed above this could be done dynamically or via information presented to a consumer. A consumer can then send a configure selecting the required Scenes/Captures/Inputs to a MCC. In the case where the information is presented/rendered to a consumer where there are large numbers of potential scenes/captures its important to give some meaning to the captures beyond Capture1, Capture2, Capture3 etc. so that a user can make a choice. That way a user can choose a capture even if it is not currently being rendered. As mentioned above the role information can also be used for rendering. Larger conferences it becomes harder to keep track of people. The role information could also be presented in other ways, e.g. a list of people who participated. In general I don't think there is any mandatory behaviour on receipt of "role" information. Like the other CLUE attributes the receiver may use the information for capture selection and rendering purposes. I think CLUE is different from other protocols where if you send element X you expect that the receiver does behaviour Y (i.e. tightly coupled). I think CLUE is more liberal in that a Advertiser sends information but the consumer doesn't actually have to use it all. Regards, Christian On 26/11/2013 1:18 AM, Michael Hammer wrote: > Christian, > > I didn't see something here, but perhaps it is stated elsewhere. > If you include an element in a protocol, it is usually good to say > what the recipient does with it. > Is the role something that will change the automated or manual > behavior of the receiving system? > Or, is it just for display? > > Also, if some of the roles affect different functions than other > roles, you may be building confusion into the protocol. > Might be good to spell that out. > > Mike > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Monday, November 25, 2013 8:06 AM > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] Roles > > Hi Cristian, > A clarification question about the usage. > I think that you are saying that there is an application usage where a > person provides his Vcard information to the system, for example, by > swiping his Company ID, and this information is provided via CLUE to > be displayed by the application on the other side of the call. > Are there other use cases or application flows that you see that will > explain the application use and flow? > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >> Groves >> Sent: 25 November, 2013 3:20 AM >> To: clue@ietf.org >> Subject: [clue] Roles >> >> Hello all, >> >> I'd like to pick up the discussion on roles from the last CLUE WG >> meeting > and >> try and make some progress via email before the design team meeting. >> >> First i'd like to clarify that "role" is not intended to be a single > attribute and it >> can have different meanings. My draft >> (draft-groves-clue-role-clarifications-00) seeks to clarify and >> provide a terminology to be more specific. I.e.: >> 2.1. Meeting Roles >> 2.2. Conference System Control Roles >> 2.3. Institution type >> 2.4. Person Name Title >> 2.5. Person Occupation (Job Title) >> 2.6. Organisation Name >> 2.7. Meeting Specific Roles >> >> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. >> 2.1 and 2.7 have also been grouped by the draft. >> >> There has been some concern that "roles" overlap with floor control. >> From the role categories above I believe this is only relevant for > "conference >> system control" roles. >> >> Secondly the intended purpose of including "roles" into CLUE is not >> for conference control or rostering but is for the selection of > Scenes/Captures and >> may be used for any subsequent rendering decisions like the other >> CLUE attributes. The focus of the CLUE work has been to focus on >> selecting > captures >> based on technical aspects (what) e.g. >> spatial properties but I think we've missed a more important aspect >> that captures will depict people or entities (who). As a consumer I'm >> likely to > be >> more interested in who rather than what. For example if I have a >> limited system and have received an Advertisement advertising 3 >> Captures(left/centre/right) and I have only one screen so must choose one. > One >> could choose the centre but this is a problem if my boss is sitting >> in the > left >> capture. >> >> Thirdly because CLUE enhances the support of multiple streams there >> is > likely >> to be a larger set of captures being advertised. Information about >> sources scenes/captures including different combinations may be sent >> to a consumer providing much more choice. Each of these >> scenes/captures may have > different >> role information. Rather than try to implement role across several > different >> methods and introduce dependencies between CLUE and other methods (e.g. >> conference package or SDP which have no Scene/capture/MCC concepts) >> it is most straightforward to send the information where it is needed >> i.e. in > CLUE. >> Fourthly we have included the "description" parameter at the >> Scene,CSE and Capture level. I think people will use those as de-facto for "role" >> type information e.g. Scene Description="Company X VIC meeting room". >> Rather than have a completely unstructured usage of description I >> think > that >> having "role" type information provided in a structured form (i.e. >> via vCard) will at least provide a consumer the ability to do some > intelligent >> processing/rendering of the information. By allowing this "role" > information to >> be sent in a structured way via CLUE I think will be an enabler for >> some interesting services and features. >> >> Finally to re-iterate what the proposal is from the draft: >> 1. The addition of a capture attribute "Meeting Role" attribute >> with values as per section 3.1 and 3.2. >> 2. The addition of a capture attribute "Conference System >> Control Role" attribute with values as per section 3.3. >> 3. The addition of a capture attribute "vCard" that allows one >> or more vCards according to [RFC6350] to be associated with a >> capture. >> 4. The addition of a capture attribute "End point vCard" that >> allows a "group", "org" or "location" kind of vCard according >> to section 6.1.4/[RFC6350] to be associated with a capture. >> >> Comments? >> >> 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 ------=_NextPart_000_0349_01CEEA23.C3595690 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEy NjAyMTczNlowIwYJKoZIhvcNAQkEMRYEFIGGevXAvNCUxPKiCpuFMVbDYoyMMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAax1f+iQJTLGtyI9ZfgRFELOCi+B8vDd56Zr4uED/ UjWOROZwXIyonXOVw7BO/zw/2/a3s0iOdZ3bVbLH0+eMPS1X4co/tKO0VZ6fqYVfBnvj8kh8htNJ L685Ujc0Ynuztq34a/l/UuR22uP4DGu4iXCNdfiPmYPtQszeVteLQsY8EIIgnClG5SWdsut3FZre /SPnNAjl22liNqquR0d7yT/wVEgHTk0NsixR4CC08A1Cw4wxu/pe/P3xidUl9mXd7Fzg6hmpVqWZ aA7bbdSZqAnY16QgnIfu06oK5GPA0amXgGhDnRSv8YtuBj+R5lDG1i43aFWFvTRgfeMB34PYRQAA AAAAAA== ------=_NextPart_000_0349_01CEEA23.C3595690-- From Christian.Groves@nteczone.com Mon Nov 25 18:45:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C061AE141 for ; Mon, 25 Nov 2013 18:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_INVITATION=-2, RDNS_DYNAMIC=0.982, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qco5bG3DbgL9 for ; Mon, 25 Nov 2013 18:44:58 -0800 (PST) Received: from cserver5.myshophosting.com (175-107-161-1.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5391AE13D for ; Mon, 25 Nov 2013 18:44:57 -0800 (PST) Received: from ppp118-209-124-146.lns20.mel4.internode.on.net ([118.209.124.146]:57663 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Vl8cr-0005Cc-OJ; Tue, 26 Nov 2013 13:43:45 +1100 Message-ID: <52940B26.5010601@nteczone.com> Date: Tue, 26 Nov 2013 13:44:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Hammer , "ron.even.tlv@gmail.com" , "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2013 02:45:02 -0000 Hello Mike, Please see below. Regards, Christian On 26/11/2013 1:17 PM, Michael Hammer wrote: > Christian, > > Appreciate the response, but there is a lot of "hand-waving" going on here. > Could you distill this down more? > > If a "role" value is received by the endpoint, can that role value by itself > be used to make a request into the system to request a change to the media > feeds from the MCC? [CNG] Yes it can. That's what I referred to in the multipoint case. Based on the role the Consumer can send a configure to the Advertiser requesting a particular MCC configuration. This will result in a change of media feeds. > > If not, does the role value need to be associated with some other concurrent > value and fed back to the MCC to do some type of selection? [CNG] Not sure what you mean here, I assume you're talking about some sort of mixing policy. There no intention that it drives mixing policy other than the selection of source captures in the MCC. > > Does the role value provided only allow local control, and not control over > the network-based feeds? [CNG] I'm not sure what you're referring to with "network-based feeds". It enables a consumer to control what it renders and allows the consumer to communicate with an Advertiser (via a configure) to control which capture encodings are sent across a network. > > Also, do *all* role values enable changes to the network traffic? [CNG] In theory yes, in practice no. E.g. if a consumer receives a vCard with a name and contact phone number associated with a capture. The consumer would most likely look at the name rather than the phone number when it comes to capture selection (and the resulting capture encoding). The phone number would be superflous capture selection and the resultant the Configure. > > Thanks, > Mike > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, November 25, 2013 9:02 PM > To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org > Subject: Re: [clue] Roles > > Hello Mike and Roni, > > In terms of usage I can see several different scenarios. > > An advertiser > ------------- > The "role" information could be pre-configured into an endpoint. E.g. a > vCard with group/organisation/location could be pre-configured so that each > time the endpoint makes a call this information is provided as a description > of the scene that is advertised. Likewise a vCard could be pre-configured > for certain captures. E.g. if you have a home based video conferencing > facility then you can have vCard with personal information (name, etc.) that > would sent each time you advertise a capture. This may be helpful for a > multi-point scenario for consumers to identify your capture. > Then there are cases where there is more dynamic setting of "role" to > scenes/captures. As Roni alluded to below there are systems where it is > possible to insert an ID card at each seating position that would allow a > system to identify people within a capture. I can see that with Smartphones > with NFC that it will be possible to get vCard style information from user's > phones. > It should also be possible to have some integration with the conference > reservation/invitation system whereby people can select where they are > sitting based on a GUI. Likewise persons could indicate their meeting role. > I.e. that they are the meeting chair, secretary etc. > > This information is then transmitted in a CLUE Advertisement. > > There is also a consideration of "roles" moving between captures. E.g. a > person moves between capture regions. I think in most cases people are > generally fairly static within a capture. In more "dynamic" cases how the > "role" mapped to capture would be dependent on how it was determined in the > first place. e.g. if someone gets up and moves between captures but leaves > their ID card in the place they were sitting then the system wouldn't track > the movement. Whereas if they swapped a seating position and swapped the ID > card then the endpoint could issue an Advertisement with the updated > information. If people are wandering back and forth between captures in a > scene then the information may be better placed at a scene level. There will > be corner cases where the role information won't be valid. I think this is > more of an application issue rather than a CLUE issue. > > > A consumer > ---------- > As indicated below the received role information may be used for capture > selection and rendering purposes. This information could be used in many > ways depending on the system/application scenario. > > For a symmetric point to point session the "role" information (as some other > CLUE attributes) is not likely to be used for capture selection as there > would be no reason to do so. However the information could be used by the > consumer for display to the users. How the information is displayed would be > dependent on the GUI. e.g. In one system the vCard information of the scene > description could be overlayed in a corner of the video. In another system > this could be made available via a menu on the video display. In other > systems this could be on a separate control monitor. > Having this information available for the users I think is a benefit because > being able to identify the people participating adds to the being there > experience particularly as CLUE is providing information about multiple > streams from an endpoint. Quite often I've been in meetings wondering who > the person was and where they are from... > > Asymmetric point to point cases is where the "role" information can be used > to select scenes/captures particularly if the consumer has less capability. > This selection of captures could be automatic (based on prior provisioning) > or manual. For example I as a user may have a regular conference with my > manager and several colleagues (three screen/camera endpoint), but I only > have 1 screen. I might set a prior policy to select captures where my > manager is located (he never sits in the same seat). Likewise I could set a > policy to always select a capture with the meeting chairman. An alternative > could be to present a list of captures and associated information at call > setup so that a user could choose. A third option is to setup a default > session and then a user could choose the captures (via a GUI) and do a > re-configure. The key is that a user has more information about the contents > of the captures. > There may be additional captures that aren't currently rendered so they > can't rely solely on visual or audio data. > > For multi-point conferences is where I see roles being very useful. Due to > the number of scenes/captures from diverse sources I think it more important > to be able to provide information about the source scenes and captures. For > example if the source scenes/captures are Advertised via an MCC and the > consumer has a limited ability to render them all then it could use either > the vCard information associated with the scene (i.e. > select a particular location) or vCard information associated with captures > (i.e. select captures representing people the consumer feels are important) > or the consumer could select scenes/captures with people important to the > meeting (i.e. chairman/scribe/etc). As discussed above this could be done > dynamically or via information presented to a consumer. A consumer can then > send a configure selecting the required Scenes/Captures/Inputs to a MCC. > > In the case where the information is presented/rendered to a consumer where > there are large numbers of potential scenes/captures its important to give > some meaning to the captures beyond Capture1, Capture2, Capture3 etc. so > that a user can make a choice. That way a user can choose a capture even if > it is not currently being rendered. As mentioned above the role information > can also be used for rendering. Larger conferences it becomes harder to keep > track of people. The role information could also be presented in other ways, > e.g. a list of people who participated. > > In general I don't think there is any mandatory behaviour on receipt of > "role" information. Like the other CLUE attributes the receiver may use the > information for capture selection and rendering purposes. I think CLUE is > different from other protocols where if you send element X you expect that > the receiver does behaviour Y (i.e. tightly coupled). I think CLUE is more > liberal in that a Advertiser sends information but the consumer doesn't > actually have to use it all. > > Regards, Christian > > On 26/11/2013 1:18 AM, Michael Hammer wrote: >> Christian, >> >> I didn't see something here, but perhaps it is stated elsewhere. >> If you include an element in a protocol, it is usually good to say >> what the recipient does with it. >> Is the role something that will change the automated or manual >> behavior of the receiving system? >> Or, is it just for display? >> >> Also, if some of the roles affect different functions than other >> roles, you may be building confusion into the protocol. >> Might be good to spell that out. >> >> Mike >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >> Sent: Monday, November 25, 2013 8:06 AM >> To: 'Christian Groves'; clue@ietf.org >> Subject: Re: [clue] Roles >> >> Hi Cristian, >> A clarification question about the usage. >> I think that you are saying that there is an application usage where a >> person provides his Vcard information to the system, for example, by >> swiping his Company ID, and this information is provided via CLUE to >> be displayed by the application on the other side of the call. >> Are there other use cases or application flows that you see that will >> explain the application use and flow? >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 25 November, 2013 3:20 AM >>> To: clue@ietf.org >>> Subject: [clue] Roles >>> >>> Hello all, >>> >>> I'd like to pick up the discussion on roles from the last CLUE WG >>> meeting >> and >>> try and make some progress via email before the design team meeting. >>> >>> First i'd like to clarify that "role" is not intended to be a single >> attribute and it >>> can have different meanings. My draft >>> (draft-groves-clue-role-clarifications-00) seeks to clarify and >>> provide a terminology to be more specific. I.e.: >>> 2.1. Meeting Roles >>> 2.2. Conference System Control Roles >>> 2.3. Institution type >>> 2.4. Person Name Title >>> 2.5. Person Occupation (Job Title) >>> 2.6. Organisation Name >>> 2.7. Meeting Specific Roles >>> >>> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. >>> 2.1 and 2.7 have also been grouped by the draft. >>> >>> There has been some concern that "roles" overlap with floor control. >>> From the role categories above I believe this is only relevant for >> "conference >>> system control" roles. >>> >>> Secondly the intended purpose of including "roles" into CLUE is not >>> for conference control or rostering but is for the selection of >> Scenes/Captures and >>> may be used for any subsequent rendering decisions like the other >>> CLUE attributes. The focus of the CLUE work has been to focus on >>> selecting >> captures >>> based on technical aspects (what) e.g. >>> spatial properties but I think we've missed a more important aspect >>> that captures will depict people or entities (who). As a consumer I'm >>> likely to >> be >>> more interested in who rather than what. For example if I have a >>> limited system and have received an Advertisement advertising 3 >>> Captures(left/centre/right) and I have only one screen so must choose > one. >> One >>> could choose the centre but this is a problem if my boss is sitting >>> in the >> left >>> capture. >>> >>> Thirdly because CLUE enhances the support of multiple streams there >>> is >> likely >>> to be a larger set of captures being advertised. Information about >>> sources scenes/captures including different combinations may be sent >>> to a consumer providing much more choice. Each of these >>> scenes/captures may have >> different >>> role information. Rather than try to implement role across several >> different >>> methods and introduce dependencies between CLUE and other methods (e.g. >>> conference package or SDP which have no Scene/capture/MCC concepts) >>> it is most straightforward to send the information where it is needed >>> i.e. in >> CLUE. >>> Fourthly we have included the "description" parameter at the >>> Scene,CSE and Capture level. I think people will use those as de-facto > for "role" >>> type information e.g. Scene Description="Company X VIC meeting room". >>> Rather than have a completely unstructured usage of description I >>> think >> that >>> having "role" type information provided in a structured form (i.e. >>> via vCard) will at least provide a consumer the ability to do some >> intelligent >>> processing/rendering of the information. By allowing this "role" >> information to >>> be sent in a structured way via CLUE I think will be an enabler for >>> some interesting services and features. >>> >>> Finally to re-iterate what the proposal is from the draft: >>> 1. The addition of a capture attribute "Meeting Role" attribute >>> with values as per section 3.1 and 3.2. >>> 2. The addition of a capture attribute "Conference System >>> Control Role" attribute with values as per section 3.3. >>> 3. The addition of a capture attribute "vCard" that allows one >>> or more vCards according to [RFC6350] to be associated with a >>> capture. >>> 4. The addition of a capture attribute "End point vCard" that >>> allows a "group", "org" or "location" kind of vCard according >>> to section 6.1.4/[RFC6350] to be associated with a capture. >>> >>> Comments? >>> >>> 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 michael.hammer@yaanatech.com Tue Nov 26 06:25:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161291AE210 for ; Tue, 26 Nov 2013 06:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.892 X-Spam-Level: X-Spam-Status: No, score=-3.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VW2dewfXu-HI for ; Tue, 26 Nov 2013 06:25:46 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 171AD1AE20B for ; Tue, 26 Nov 2013 06:25:45 -0800 (PST) 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; Tue, 26 Nov 2013 06:25:45 -0800 From: Michael Hammer To: "Christian.Groves@nteczone.com" , "ron.even.tlv@gmail.com" , "clue@ietf.org" Thread-Topic: [clue] Roles Thread-Index: AQHO6XyDoz4IP0c9LUeTUk2PvJY9X5o2cWGA//+MyJCAAUwXAP//fCwggACPrwCAADnZQA== Date: Tue, 26 Nov 2013 14:25:44 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFDE62@sc9-ex2k10mb1.corp.yaanatech.com> References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> <52940B26.5010601@nteczone.com> In-Reply-To: <52940B26.5010601@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.244] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000A_01CEEA89.7ACA71F0" MIME-Version: 1.0 Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2013 14:25:49 -0000 ------=_NextPart_000_000A_01CEEA89.7ACA71F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Inline. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: Monday, November 25, 2013 9:45 PM To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org Subject: Re: [clue] Roles Hello Mike, Please see below. Regards, Christian On 26/11/2013 1:17 PM, Michael Hammer wrote: > Christian, > > Appreciate the response, but there is a lot of "hand-waving" going on here. > Could you distill this down more? > > If a "role" value is received by the endpoint, can that role value by > itself be used to make a request into the system to request a change > to the media feeds from the MCC? [CNG] Yes it can. That's what I referred to in the multipoint case. Based on the role the Consumer can send a configure to the Advertiser requesting a particular MCC configuration. This will result in a change of media feeds. Phrases like "based on the role" is where things get mushy for me. I assume you are saying the role is the key value sent to the MCC to stop or start delivery of a particular media. > > If not, does the role value need to be associated with some other concurrent > value and fed back to the MCC to do some type of selection? [CNG] Not sure what you mean here, I assume you're talking about some sort of mixing policy. There no intention that it drives mixing policy other than the selection of source captures in the MCC. What I meant was that the role needs to be linked to another value. That other value is then used to indicate to the MCC what to send or not send. > > Does the role value provided only allow local control, and not control over > the network-based feeds? [CNG] I'm not sure what you're referring to with "network-based feeds". It enables a consumer to control what it renders and allows the consumer to communicate with an Advertiser (via a configure) to control which capture encodings are sent across a network. What I was thinking here was that as an alternative to the above, what you get from the MCC is what you get, and the role is only used to select locally what to render. I was just thinking through different alternatives of how it might work from your descriptions. Thanks, Mike > > Also, do *all* role values enable changes to the network traffic? [CNG] In theory yes, in practice no. E.g. if a consumer receives a vCard with a name and contact phone number associated with a capture. The consumer would most likely look at the name rather than the phone number when it comes to capture selection (and the resulting capture encoding). The phone number would be superflous capture selection and the resultant the Configure. > > Thanks, > Mike > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, November 25, 2013 9:02 PM > To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org > Subject: Re: [clue] Roles > > Hello Mike and Roni, > > In terms of usage I can see several different scenarios. > > An advertiser > ------------- > The "role" information could be pre-configured into an endpoint. E.g. a > vCard with group/organisation/location could be pre-configured so that each > time the endpoint makes a call this information is provided as a description > of the scene that is advertised. Likewise a vCard could be pre-configured > for certain captures. E.g. if you have a home based video conferencing > facility then you can have vCard with personal information (name, etc.) that > would sent each time you advertise a capture. This may be helpful for a > multi-point scenario for consumers to identify your capture. > Then there are cases where there is more dynamic setting of "role" to > scenes/captures. As Roni alluded to below there are systems where it is > possible to insert an ID card at each seating position that would allow a > system to identify people within a capture. I can see that with Smartphones > with NFC that it will be possible to get vCard style information from user's > phones. > It should also be possible to have some integration with the conference > reservation/invitation system whereby people can select where they are > sitting based on a GUI. Likewise persons could indicate their meeting role. > I.e. that they are the meeting chair, secretary etc. > > This information is then transmitted in a CLUE Advertisement. > > There is also a consideration of "roles" moving between captures. E.g. a > person moves between capture regions. I think in most cases people are > generally fairly static within a capture. In more "dynamic" cases how the > "role" mapped to capture would be dependent on how it was determined in the > first place. e.g. if someone gets up and moves between captures but leaves > their ID card in the place they were sitting then the system wouldn't track > the movement. Whereas if they swapped a seating position and swapped the ID > card then the endpoint could issue an Advertisement with the updated > information. If people are wandering back and forth between captures in a > scene then the information may be better placed at a scene level. There will > be corner cases where the role information won't be valid. I think this is > more of an application issue rather than a CLUE issue. > > > A consumer > ---------- > As indicated below the received role information may be used for capture > selection and rendering purposes. This information could be used in many > ways depending on the system/application scenario. > > For a symmetric point to point session the "role" information (as some other > CLUE attributes) is not likely to be used for capture selection as there > would be no reason to do so. However the information could be used by the > consumer for display to the users. How the information is displayed would be > dependent on the GUI. e.g. In one system the vCard information of the scene > description could be overlayed in a corner of the video. In another system > this could be made available via a menu on the video display. In other > systems this could be on a separate control monitor. > Having this information available for the users I think is a benefit because > being able to identify the people participating adds to the being there > experience particularly as CLUE is providing information about multiple > streams from an endpoint. Quite often I've been in meetings wondering who > the person was and where they are from... > > Asymmetric point to point cases is where the "role" information can be used > to select scenes/captures particularly if the consumer has less capability. > This selection of captures could be automatic (based on prior provisioning) > or manual. For example I as a user may have a regular conference with my > manager and several colleagues (three screen/camera endpoint), but I only > have 1 screen. I might set a prior policy to select captures where my > manager is located (he never sits in the same seat). Likewise I could set a > policy to always select a capture with the meeting chairman. An alternative > could be to present a list of captures and associated information at call > setup so that a user could choose. A third option is to setup a default > session and then a user could choose the captures (via a GUI) and do a > re-configure. The key is that a user has more information about the contents > of the captures. > There may be additional captures that aren't currently rendered so they > can't rely solely on visual or audio data. > > For multi-point conferences is where I see roles being very useful. Due to > the number of scenes/captures from diverse sources I think it more important > to be able to provide information about the source scenes and captures. For > example if the source scenes/captures are Advertised via an MCC and the > consumer has a limited ability to render them all then it could use either > the vCard information associated with the scene (i.e. > select a particular location) or vCard information associated with captures > (i.e. select captures representing people the consumer feels are important) > or the consumer could select scenes/captures with people important to the > meeting (i.e. chairman/scribe/etc). As discussed above this could be done > dynamically or via information presented to a consumer. A consumer can then > send a configure selecting the required Scenes/Captures/Inputs to a MCC. > > In the case where the information is presented/rendered to a consumer where > there are large numbers of potential scenes/captures its important to give > some meaning to the captures beyond Capture1, Capture2, Capture3 etc. so > that a user can make a choice. That way a user can choose a capture even if > it is not currently being rendered. As mentioned above the role information > can also be used for rendering. Larger conferences it becomes harder to keep > track of people. The role information could also be presented in other ways, > e.g. a list of people who participated. > > In general I don't think there is any mandatory behaviour on receipt of > "role" information. Like the other CLUE attributes the receiver may use the > information for capture selection and rendering purposes. I think CLUE is > different from other protocols where if you send element X you expect that > the receiver does behaviour Y (i.e. tightly coupled). I think CLUE is more > liberal in that a Advertiser sends information but the consumer doesn't > actually have to use it all. > > Regards, Christian > > On 26/11/2013 1:18 AM, Michael Hammer wrote: >> Christian, >> >> I didn't see something here, but perhaps it is stated elsewhere. >> If you include an element in a protocol, it is usually good to say >> what the recipient does with it. >> Is the role something that will change the automated or manual >> behavior of the receiving system? >> Or, is it just for display? >> >> Also, if some of the roles affect different functions than other >> roles, you may be building confusion into the protocol. >> Might be good to spell that out. >> >> Mike >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >> Sent: Monday, November 25, 2013 8:06 AM >> To: 'Christian Groves'; clue@ietf.org >> Subject: Re: [clue] Roles >> >> Hi Cristian, >> A clarification question about the usage. >> I think that you are saying that there is an application usage where a >> person provides his Vcard information to the system, for example, by >> swiping his Company ID, and this information is provided via CLUE to >> be displayed by the application on the other side of the call. >> Are there other use cases or application flows that you see that will >> explain the application use and flow? >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 25 November, 2013 3:20 AM >>> To: clue@ietf.org >>> Subject: [clue] Roles >>> >>> Hello all, >>> >>> I'd like to pick up the discussion on roles from the last CLUE WG >>> meeting >> and >>> try and make some progress via email before the design team meeting. >>> >>> First i'd like to clarify that "role" is not intended to be a single >> attribute and it >>> can have different meanings. My draft >>> (draft-groves-clue-role-clarifications-00) seeks to clarify and >>> provide a terminology to be more specific. I.e.: >>> 2.1. Meeting Roles >>> 2.2. Conference System Control Roles >>> 2.3. Institution type >>> 2.4. Person Name Title >>> 2.5. Person Occupation (Job Title) >>> 2.6. Organisation Name >>> 2.7. Meeting Specific Roles >>> >>> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. >>> 2.1 and 2.7 have also been grouped by the draft. >>> >>> There has been some concern that "roles" overlap with floor control. >>> From the role categories above I believe this is only relevant for >> "conference >>> system control" roles. >>> >>> Secondly the intended purpose of including "roles" into CLUE is not >>> for conference control or rostering but is for the selection of >> Scenes/Captures and >>> may be used for any subsequent rendering decisions like the other >>> CLUE attributes. The focus of the CLUE work has been to focus on >>> selecting >> captures >>> based on technical aspects (what) e.g. >>> spatial properties but I think we've missed a more important aspect >>> that captures will depict people or entities (who). As a consumer I'm >>> likely to >> be >>> more interested in who rather than what. For example if I have a >>> limited system and have received an Advertisement advertising 3 >>> Captures(left/centre/right) and I have only one screen so must choose > one. >> One >>> could choose the centre but this is a problem if my boss is sitting >>> in the >> left >>> capture. >>> >>> Thirdly because CLUE enhances the support of multiple streams there >>> is >> likely >>> to be a larger set of captures being advertised. Information about >>> sources scenes/captures including different combinations may be sent >>> to a consumer providing much more choice. Each of these >>> scenes/captures may have >> different >>> role information. Rather than try to implement role across several >> different >>> methods and introduce dependencies between CLUE and other methods (e.g. >>> conference package or SDP which have no Scene/capture/MCC concepts) >>> it is most straightforward to send the information where it is needed >>> i.e. in >> CLUE. >>> Fourthly we have included the "description" parameter at the >>> Scene,CSE and Capture level. I think people will use those as de-facto > for "role" >>> type information e.g. Scene Description="Company X VIC meeting room". >>> Rather than have a completely unstructured usage of description I >>> think >> that >>> having "role" type information provided in a structured form (i.e. >>> via vCard) will at least provide a consumer the ability to do some >> intelligent >>> processing/rendering of the information. By allowing this "role" >> information to >>> be sent in a structured way via CLUE I think will be an enabler for >>> some interesting services and features. >>> >>> Finally to re-iterate what the proposal is from the draft: >>> 1. The addition of a capture attribute "Meeting Role" attribute >>> with values as per section 3.1 and 3.2. >>> 2. The addition of a capture attribute "Conference System >>> Control Role" attribute with values as per section 3.3. >>> 3. The addition of a capture attribute "vCard" that allows one >>> or more vCards according to [RFC6350] to be associated with a >>> capture. >>> 4. The addition of a capture attribute "End point vCard" that >>> allows a "group", "org" or "location" kind of vCard according >>> to section 6.1.4/[RFC6350] to be associated with a capture. >>> >>> Comments? >>> >>> 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 ------=_NextPart_000_000A_01CEEA89.7ACA71F0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEy NjE0MjU0M1owIwYJKoZIhvcNAQkEMRYEFBrAOGqnC+ao3Gi2uVyWIXVtCaHNMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAR/P4BMWJioDDSZPFC2Yf4iDB87ALixHDATQhWjQP GxwwMgoI7O3wT6icI1dAUKysN84AMSjBBtJgyWoN5cNHCjRh0W5Hu9QmFjXvR8XCClZMrlvJlTuZ XdQ0dsa+facqK1bwVFEulTunRN6RUgQk85u6KHPsWqCKVgZK/LEjfsNbuuGbiXNbNnBnj6K4nfmw N35Jvx3mcekmernJCnsQMF3gYd7lsevi42DdMF8fEMZSHgsOuiuc7o9KNnquTUtkalFw/R9rlhfy FhpovZPwmx+5DE+U73aBWmtzSDHVFlkcpBajdGp0Q6f4di94N/gFsAT9qOZsBJvOlSbJT7jcvAAA AAAAAA== ------=_NextPart_000_000A_01CEEA89.7ACA71F0-- From pkyzivat@alum.mit.edu Tue Nov 26 09:30:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF011ADF73 for ; Tue, 26 Nov 2013 09:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_INVITATION=-2, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6HQK-BmtaF5 for ; Tue, 26 Nov 2013 09:30:13 -0800 (PST) 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 935DC1ADF59 for ; Tue, 26 Nov 2013 09:30:13 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id uCbL1m0011YDfWL56HWDim; Tue, 26 Nov 2013 17:30:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id uHWC1m0043ZTu2S3gHWCYy; Tue, 26 Nov 2013 17:30:12 +0000 Message-ID: <5294DAA4.4060509@alum.mit.edu> Date: Tue, 26 Nov 2013 09:30:12 -0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.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=1385487013; bh=EmZ0oddTqdi+KjTWXwPxgfalXCBWKAE8X6xZvNxljtg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kgmdkvXFMcg1prwtaOmvI2ETtiuKAFdUig6SJVuwv+gQw37itjjOXQhKS4wLN01lW X/z0nskiXu60qSsWEwl+10pYV4mE2XJFbYX0SGd9OOTGvpktVoheCaH0tA4Z7iY00v E26c66lN4KksyOR1ErM4wTQKfl/YYDH0G4ujtT1hgAfo081/XXKM/YaVTlTUtWt0IO hZPpEQAQtEPxFTKdXl8h3j6ZOSE7JKF9YltByCsiaFS+HGkKJla17jbNeLLDzbQLCt aylNnmQloPisqoYs2DkX2ZDVjqjzWYIoVYLfGUvsM1gxvPwSvnqe1UXk/ioG7uXe7t iB3PixC45SmrQ== Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2013 17:30:17 -0000 On 11/25/13 6:17 PM, Michael Hammer wrote: > Christian, > > Appreciate the response, but there is a lot of "hand-waving" going on here. > Could you distill this down more? > > If a "role" value is received by the endpoint, can that role value by itself > be used to make a request into the system to request a change to the media > feeds from the MCC? Roles are attributes of captures. They aren't used in Configure messages. The consumer endpoint can "use" the Role (locally) when choosing which captures it wants to configure. It can be considered by an *algorithm* that automatically chooses captures, or it can make that information available to a user, and allow the user to make the choice. Thanks, Paul > If not, does the role value need to be associated with some other concurrent > value and fed back to the MCC to do some type of selection? > > Does the role value provided only allow local control, and not control over > the network-based feeds? > > Also, do *all* role values enable changes to the network traffic? > > Thanks, > Mike > > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, November 25, 2013 9:02 PM > To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org > Subject: Re: [clue] Roles > > Hello Mike and Roni, > > In terms of usage I can see several different scenarios. > > An advertiser > ------------- > The "role" information could be pre-configured into an endpoint. E.g. a > vCard with group/organisation/location could be pre-configured so that each > time the endpoint makes a call this information is provided as a description > of the scene that is advertised. Likewise a vCard could be pre-configured > for certain captures. E.g. if you have a home based video conferencing > facility then you can have vCard with personal information (name, etc.) that > would sent each time you advertise a capture. This may be helpful for a > multi-point scenario for consumers to identify your capture. > Then there are cases where there is more dynamic setting of "role" to > scenes/captures. As Roni alluded to below there are systems where it is > possible to insert an ID card at each seating position that would allow a > system to identify people within a capture. I can see that with Smartphones > with NFC that it will be possible to get vCard style information from user's > phones. > It should also be possible to have some integration with the conference > reservation/invitation system whereby people can select where they are > sitting based on a GUI. Likewise persons could indicate their meeting role. > I.e. that they are the meeting chair, secretary etc. > > This information is then transmitted in a CLUE Advertisement. > > There is also a consideration of "roles" moving between captures. E.g. a > person moves between capture regions. I think in most cases people are > generally fairly static within a capture. In more "dynamic" cases how the > "role" mapped to capture would be dependent on how it was determined in the > first place. e.g. if someone gets up and moves between captures but leaves > their ID card in the place they were sitting then the system wouldn't track > the movement. Whereas if they swapped a seating position and swapped the ID > card then the endpoint could issue an Advertisement with the updated > information. If people are wandering back and forth between captures in a > scene then the information may be better placed at a scene level. There will > be corner cases where the role information won't be valid. I think this is > more of an application issue rather than a CLUE issue. > > > A consumer > ---------- > As indicated below the received role information may be used for capture > selection and rendering purposes. This information could be used in many > ways depending on the system/application scenario. > > For a symmetric point to point session the "role" information (as some other > CLUE attributes) is not likely to be used for capture selection as there > would be no reason to do so. However the information could be used by the > consumer for display to the users. How the information is displayed would be > dependent on the GUI. e.g. In one system the vCard information of the scene > description could be overlayed in a corner of the video. In another system > this could be made available via a menu on the video display. In other > systems this could be on a separate control monitor. > Having this information available for the users I think is a benefit because > being able to identify the people participating adds to the being there > experience particularly as CLUE is providing information about multiple > streams from an endpoint. Quite often I've been in meetings wondering who > the person was and where they are from... > > Asymmetric point to point cases is where the "role" information can be used > to select scenes/captures particularly if the consumer has less capability. > This selection of captures could be automatic (based on prior provisioning) > or manual. For example I as a user may have a regular conference with my > manager and several colleagues (three screen/camera endpoint), but I only > have 1 screen. I might set a prior policy to select captures where my > manager is located (he never sits in the same seat). Likewise I could set a > policy to always select a capture with the meeting chairman. An alternative > could be to present a list of captures and associated information at call > setup so that a user could choose. A third option is to setup a default > session and then a user could choose the captures (via a GUI) and do a > re-configure. The key is that a user has more information about the contents > of the captures. > There may be additional captures that aren't currently rendered so they > can't rely solely on visual or audio data. > > For multi-point conferences is where I see roles being very useful. Due to > the number of scenes/captures from diverse sources I think it more important > to be able to provide information about the source scenes and captures. For > example if the source scenes/captures are Advertised via an MCC and the > consumer has a limited ability to render them all then it could use either > the vCard information associated with the scene (i.e. > select a particular location) or vCard information associated with captures > (i.e. select captures representing people the consumer feels are important) > or the consumer could select scenes/captures with people important to the > meeting (i.e. chairman/scribe/etc). As discussed above this could be done > dynamically or via information presented to a consumer. A consumer can then > send a configure selecting the required Scenes/Captures/Inputs to a MCC. > > In the case where the information is presented/rendered to a consumer where > there are large numbers of potential scenes/captures its important to give > some meaning to the captures beyond Capture1, Capture2, Capture3 etc. so > that a user can make a choice. That way a user can choose a capture even if > it is not currently being rendered. As mentioned above the role information > can also be used for rendering. Larger conferences it becomes harder to keep > track of people. The role information could also be presented in other ways, > e.g. a list of people who participated. > > In general I don't think there is any mandatory behaviour on receipt of > "role" information. Like the other CLUE attributes the receiver may use the > information for capture selection and rendering purposes. I think CLUE is > different from other protocols where if you send element X you expect that > the receiver does behaviour Y (i.e. tightly coupled). I think CLUE is more > liberal in that a Advertiser sends information but the consumer doesn't > actually have to use it all. > > Regards, Christian > > On 26/11/2013 1:18 AM, Michael Hammer wrote: >> Christian, >> >> I didn't see something here, but perhaps it is stated elsewhere. >> If you include an element in a protocol, it is usually good to say >> what the recipient does with it. >> Is the role something that will change the automated or manual >> behavior of the receiving system? >> Or, is it just for display? >> >> Also, if some of the roles affect different functions than other >> roles, you may be building confusion into the protocol. >> Might be good to spell that out. >> >> Mike >> >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >> Sent: Monday, November 25, 2013 8:06 AM >> To: 'Christian Groves'; clue@ietf.org >> Subject: Re: [clue] Roles >> >> Hi Cristian, >> A clarification question about the usage. >> I think that you are saying that there is an application usage where a >> person provides his Vcard information to the system, for example, by >> swiping his Company ID, and this information is provided via CLUE to >> be displayed by the application on the other side of the call. >> Are there other use cases or application flows that you see that will >> explain the application use and flow? >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>> Groves >>> Sent: 25 November, 2013 3:20 AM >>> To: clue@ietf.org >>> Subject: [clue] Roles >>> >>> Hello all, >>> >>> I'd like to pick up the discussion on roles from the last CLUE WG >>> meeting >> and >>> try and make some progress via email before the design team meeting. >>> >>> First i'd like to clarify that "role" is not intended to be a single >> attribute and it >>> can have different meanings. My draft >>> (draft-groves-clue-role-clarifications-00) seeks to clarify and >>> provide a terminology to be more specific. I.e.: >>> 2.1. Meeting Roles >>> 2.2. Conference System Control Roles >>> 2.3. Institution type >>> 2.4. Person Name Title >>> 2.5. Person Occupation (Job Title) >>> 2.6. Organisation Name >>> 2.7. Meeting Specific Roles >>> >>> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the draft. >>> 2.1 and 2.7 have also been grouped by the draft. >>> >>> There has been some concern that "roles" overlap with floor control. >>> From the role categories above I believe this is only relevant for >> "conference >>> system control" roles. >>> >>> Secondly the intended purpose of including "roles" into CLUE is not >>> for conference control or rostering but is for the selection of >> Scenes/Captures and >>> may be used for any subsequent rendering decisions like the other >>> CLUE attributes. The focus of the CLUE work has been to focus on >>> selecting >> captures >>> based on technical aspects (what) e.g. >>> spatial properties but I think we've missed a more important aspect >>> that captures will depict people or entities (who). As a consumer I'm >>> likely to >> be >>> more interested in who rather than what. For example if I have a >>> limited system and have received an Advertisement advertising 3 >>> Captures(left/centre/right) and I have only one screen so must choose > one. >> One >>> could choose the centre but this is a problem if my boss is sitting >>> in the >> left >>> capture. >>> >>> Thirdly because CLUE enhances the support of multiple streams there >>> is >> likely >>> to be a larger set of captures being advertised. Information about >>> sources scenes/captures including different combinations may be sent >>> to a consumer providing much more choice. Each of these >>> scenes/captures may have >> different >>> role information. Rather than try to implement role across several >> different >>> methods and introduce dependencies between CLUE and other methods (e.g. >>> conference package or SDP which have no Scene/capture/MCC concepts) >>> it is most straightforward to send the information where it is needed >>> i.e. in >> CLUE. >>> Fourthly we have included the "description" parameter at the >>> Scene,CSE and Capture level. I think people will use those as de-facto > for "role" >>> type information e.g. Scene Description="Company X VIC meeting room". >>> Rather than have a completely unstructured usage of description I >>> think >> that >>> having "role" type information provided in a structured form (i.e. >>> via vCard) will at least provide a consumer the ability to do some >> intelligent >>> processing/rendering of the information. By allowing this "role" >> information to >>> be sent in a structured way via CLUE I think will be an enabler for >>> some interesting services and features. >>> >>> Finally to re-iterate what the proposal is from the draft: >>> 1. The addition of a capture attribute "Meeting Role" attribute >>> with values as per section 3.1 and 3.2. >>> 2. The addition of a capture attribute "Conference System >>> Control Role" attribute with values as per section 3.3. >>> 3. The addition of a capture attribute "vCard" that allows one >>> or more vCards according to [RFC6350] to be associated with a >>> capture. >>> 4. The addition of a capture attribute "End point vCard" that >>> allows a "group", "org" or "location" kind of vCard according >>> to section 6.1.4/[RFC6350] to be associated with a capture. >>> >>> Comments? >>> >>> 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 > From Christian.Groves@nteczone.com Tue Nov 26 18:42:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EF1AE0D2 for ; Tue, 26 Nov 2013 18:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKy_ZOcov1xA for ; Tue, 26 Nov 2013 18:42:32 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469FB1AE0A0 for ; Tue, 26 Nov 2013 18:42:32 -0800 (PST) Received: from ppp118-209-23-29.lns20.mel4.internode.on.net ([118.209.23.29]:55744 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VlV3p-0004Y8-8O; Wed, 27 Nov 2013 13:41:05 +1100 Message-ID: <52955C12.4040308@nteczone.com> Date: Wed, 27 Nov 2013 13:42:26 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Michael Hammer , "ron.even.tlv@gmail.com" , "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> <52940B26.5010601@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDE62@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBEFDE62@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 02:42:35 -0000 Hello Mike, I think we have two different thoughts about usage here. Please see below. Regards, Christian ..snip.. >> Could you distill this down more? >> >> If a "role" value is received by the endpoint, can that role value by >> itself be used to make a request into the system to request a change >> to the media feeds from the MCC? > [CNG] Yes it can. That's what I referred to in the multipoint case. > Based on the role the Consumer can send a configure to the Advertiser > requesting a particular MCC configuration. This will result in a change of > media feeds. > > Phrases like "based on the role" is where things get mushy for me. > I assume you are saying the role is the key value sent to the MCC to stop or > start delivery of a particular media. [CNG] Don't think of role being used as a control value. Its not like floor control. When I talk about it being used to select media streams and the resultant encoding I mean something like the examples below: Advertisement Scene1(vCard[location=USconferenceroom]), VC1 Scene2(vCard[location=Australiaconferenceroom]), VC2 Scene3(vCard[location=ChinaConferenceroom]),VC3 Scene4 (MCC1(VC1,VC2,VC3), Encoding1 The consumer receives the above Advertisement and looks at the "role" information i.e. the vCard associated with the contributing scenes and decides that it only wants to see the US and China conference rooms. The consumer then sends a Configure. Configure MCC1(VC1,VC3),Encoding1 Another example at the capture level: Advertisement Scene1 VC1(vCard[name=Tom]) VC2(vCard[name=John]) VC3(vCard[name=Margaret]) CSE(VC1,VC2,VC3) Encoding1 The consumer only has one screen and receives the Advertisement above. It can't / doesn't want to receive all the streams. The user regularly has this conference. Margaret is the user's manager, Tom and John are colleagues. The user/consumer uses the role (vCard) information to decide to only receive VC3. The consumer then sends a configure: Configure VC3,Encoding1 > >> If not, does the role value need to be associated with some other > concurrent >> value and fed back to the MCC to do some type of selection? > [CNG] Not sure what you mean here, I assume you're talking about some > sort of mixing policy. There no intention that it drives mixing policy > other than the selection of source captures in the MCC. > > What I meant was that the role needs to be linked to another value. > That other value is then used to indicate to the MCC what to send or not > send. [CNG] I think we maybe getting mixed up with the MCC policy attribute. I.e. setting a policy that determines what is being sent, i.e. activespeaker, round robin etc. I think that's a separate discussion. > >> Does the role value provided only allow local control, and not control > over >> the network-based feeds? > [CNG] I'm not sure what you're referring to with "network-based feeds". > It enables a consumer to control what it renders and allows the consumer > to communicate with an Advertiser (via a configure) to control which > capture encodings are sent across a network. > > What I was thinking here was that as an alternative to the above, > what you get from the MCC is what you get, > and the role is only used to select locally what to render. > > I was just thinking through different alternatives of how it might work from > your descriptions. > Thanks, Mike > > From michael.hammer@yaanatech.com Wed Nov 27 06:25:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD1D1ADF86 for ; Wed, 27 Nov 2013 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnDR-QHSXZbQ for ; Wed, 27 Nov 2013 06:25:25 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id AC13C1AD75F for ; Wed, 27 Nov 2013 06:25:24 -0800 (PST) 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, 27 Nov 2013 06:25:23 -0800 From: Michael Hammer To: "Christian.Groves@nteczone.com" , "ron.even.tlv@gmail.com" , "clue@ietf.org" Thread-Topic: [clue] Roles Thread-Index: AQHO6XyDoz4IP0c9LUeTUk2PvJY9X5o2cWGA//+MyJCAAUwXAP//fCwggACPrwCAADnZQIABV8wAgAA+OQA= Date: Wed, 27 Nov 2013 14:25:22 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEFE6A5@sc9-ex2k10mb1.corp.yaanatech.com> References: <5292A5CE.4050605@nteczone.com> <0b5001cee9df$2193db80$64bb9280$@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBEFD56D@sc9-ex2k10mb1.corp.yaanatech.com> <52940134.7090301@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDD3B@sc9-ex2k10mb1.corp.yaanatech.com> <52940B26.5010601@nteczone.com> <00C069FD01E0324C9FFCADF539701DB3BBEFDE62@sc9-ex2k10mb1.corp.yaanatech.com> <52955C12.4040308@nteczone.com> In-Reply-To: <52955C12.4040308@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.21] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001E_01CEEB52.98980BB0" MIME-Version: 1.0 Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 14:25:29 -0000 ------=_NextPart_000_001E_01CEEB52.98980BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks, that makes it much clearer for me. Mike -----Original Message----- From: Christian Groves [mailto:Christian.Groves@nteczone.com] Sent: Tuesday, November 26, 2013 9:42 PM To: Michael Hammer; ron.even.tlv@gmail.com; clue@ietf.org Subject: Re: [clue] Roles Hello Mike, I think we have two different thoughts about usage here. Please see below. Regards, Christian ..snip.. >> Could you distill this down more? >> >> If a "role" value is received by the endpoint, can that role value by >> itself be used to make a request into the system to request a change >> to the media feeds from the MCC? > [CNG] Yes it can. That's what I referred to in the multipoint case. > Based on the role the Consumer can send a configure to the Advertiser > requesting a particular MCC configuration. This will result in a > change of media feeds. > > Phrases like "based on the role" is where things get mushy for me. > I assume you are saying the role is the key value sent to the MCC to > stop or start delivery of a particular media. [CNG] Don't think of role being used as a control value. Its not like floor control. When I talk about it being used to select media streams and the resultant encoding I mean something like the examples below: Advertisement Scene1(vCard[location=USconferenceroom]), VC1 Scene2(vCard[location=Australiaconferenceroom]), VC2 Scene3(vCard[location=ChinaConferenceroom]),VC3 Scene4 (MCC1(VC1,VC2,VC3), Encoding1 The consumer receives the above Advertisement and looks at the "role" information i.e. the vCard associated with the contributing scenes and decides that it only wants to see the US and China conference rooms. The consumer then sends a Configure. Configure MCC1(VC1,VC3),Encoding1 Another example at the capture level: Advertisement Scene1 VC1(vCard[name=Tom]) VC2(vCard[name=John]) VC3(vCard[name=Margaret]) CSE(VC1,VC2,VC3) Encoding1 The consumer only has one screen and receives the Advertisement above. It can't / doesn't want to receive all the streams. The user regularly has this conference. Margaret is the user's manager, Tom and John are colleagues. The user/consumer uses the role (vCard) information to decide to only receive VC3. The consumer then sends a configure: Configure VC3,Encoding1 > >> If not, does the role value need to be associated with some other > concurrent >> value and fed back to the MCC to do some type of selection? > [CNG] Not sure what you mean here, I assume you're talking about some > sort of mixing policy. There no intention that it drives mixing policy > other than the selection of source captures in the MCC. > > What I meant was that the role needs to be linked to another value. > That other value is then used to indicate to the MCC what to send or > not send. [CNG] I think we maybe getting mixed up with the MCC policy attribute. I.e. setting a policy that determines what is being sent, i.e. activespeaker, round robin etc. I think that's a separate discussion. > >> Does the role value provided only allow local control, and not >> control > over >> the network-based feeds? > [CNG] I'm not sure what you're referring to with "network-based feeds". > It enables a consumer to control what it renders and allows the > consumer to communicate with an Advertiser (via a configure) to > control which capture encodings are sent across a network. > > What I was thinking here was that as an alternative to the above, what > you get from the MCC is what you get, and the role is only used to > select locally what to render. > > I was just thinking through different alternatives of how it might > work from your descriptions. > Thanks, Mike > > ------=_NextPart_000_001E_01CEEB52.98980BB0 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 AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTEy NzE0MjUyMlowIwYJKoZIhvcNAQkEMRYEFE2PBB0NQzdf6xGNwkBr8qrvUdjiMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAT5ZS6AtTj4rk5nfvNpsg6GA9872lp5MO8/2bGJus dhPSNHrKwj387BG/tJYiMMTynY0yP76m2OKfin4ZumvV/KflbUyNDXKjSgcEZw/i43oKV/AsXh5h 0UL4BplB0xk+CstSXKcygOoyc8Q/7SXFBkJV7SIPuBYKlbKFsSq57K4cdjesoMgkI/yEofnHjscT N+80BLeqT3gVIqrRKTe5TzRhiSsEZPXpZA6qQ1h2ZnN8PyRnAYRaQ0jj7AmtmQ4w+FimbHq05RK5 DShR/cOOj4/hU5a+rHnajyC8kuRHU6hOsFqX12emk095GCn7YaRm/qXumobputLn6oEd1kd3JwAA AAAAAA== ------=_NextPart_000_001E_01CEEB52.98980BB0-- From stephen.botzko@gmail.com Wed Nov 27 14:28:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133C81AE184 for ; Wed, 27 Nov 2013 14:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QfCP89OM8Ts for ; Wed, 27 Nov 2013 14:27:56 -0800 (PST) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 488121AE185 for ; Wed, 27 Nov 2013 14:27:56 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id lh4so5240932vcb.23 for ; Wed, 27 Nov 2013 14:27:55 -0800 (PST) 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=+2WM/ouzJLoWZ6Xoz/6bmMEmn+Al6uG+VSUGV0GB3K8=; b=tOcYOT5biZZ2YJTg71ZvoLkzeMYuRyyONpDeK2y6T3IoWdinWm4uLxLWlwMwnLVQCU cgOO52a15OY5PuLf+RVS+4jAdmNyZJcDbfl7XU7KsEJfUDAnDKo1RNDQ8RuGX3wN/rPv nCGRPhHpc8Qi+bXPyjzUA/+AK1fsPuD2yQP+I/M22LfP1rY/Qzduebk4+Q3Fb6osYmGM dEqqqG1PMAGSYuvLPV3YvWJgdTjAuPy+k7q17EzfcOPLLhRTTksGDQkMZtuciwzDcXQ0 VsA9gc7on5zIhXZ4lNL/oRww+YkhXHeqDvDS0ZX8qXBY91FKkCZyLwsEh+M7NUoa8R+5 pT8g== MIME-Version: 1.0 X-Received: by 10.221.51.5 with SMTP id vg5mr1386251vcb.40.1385591275483; Wed, 27 Nov 2013 14:27:55 -0800 (PST) Received: by 10.220.187.68 with HTTP; Wed, 27 Nov 2013 14:27:55 -0800 (PST) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> Date: Wed, 27 Nov 2013 17:27:55 -0500 Message-ID: From: Stephen Botzko To: Mary Barnes Content-Type: multipart/alternative; boundary=001a11335afcc776a504ec301b87 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 27 Nov 2013 22:28:02 -0000 --001a11335afcc776a504ec301b87 Content-Type: text/plain; charset=ISO-8859-1 Dan - thanks so much for reviewing this. Comments are in-line Stephen Botzko On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes wrote: > On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat wrote: > >> Authors, >> >> What do you think of these comments? >> If you aren't in agreement with all of them, then we should have a dialog >> with Dan about them. >> >> If in agreement, then lets discuss what changes are appropriate. >> >> More inline. >> >> >> On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: >> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> . >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-clue-telepresence-requirements-06.txt >>> Reviewer: Dan Romascanu >>> Review Date: 11/21/13 >>> IETF LC End Date: 11/27/13 >>> IESG Telechat date: (if known) >>> >>> Summary: It's a good and well written document, almost ready, but a >>> number of issues should be clarified before approval. >>> >>> Major issues: >>> >>> 1. The definitions of Left and Right in Section 3 use an entry article >>> in Wikipedia ('Stage Directions'). I am both uncomfortable with the usage >>> of Wikipedia articles (subject to change, subject to attacks) as >>> references, and I also believe that the current definitions (@11/21/13, US >>> morning hours) are ambiguous. Actually the Wikipedia article does not >>> include definitions for Left and Right, and speaks about 'house left' >>> (equal to 'stage right') and 'house right' (equal to 'stage left'). If >>> another specification in CLUE will use the terms defined here it is not >>> clear which one is meant. >>> >> >> This seems like a reasonable point to me. Is there a more stable >> reference we can use? If not, can we just define these terms in the >> document? > > [MB] I'm almost of a mind to just remove those definitions. The consensus > was that the terms should be qualified when they are used and the framework > does an excellent job of defining more precise terms that properly qualify > "left" and "right" and differentiate from stage right, etc. as appropriate. > We use "left" and "right" in one place in this requirements document and I > think the use is general enough that we don't need a definition (in this > document). The wikipedia reference has been in the document since day 1 > as a WG document (it was added in -03 of the individual document). The > discussions around "left"/"right" on the list were in the context of the > definitions document and again, consensus was that the terms should be > qualified (as they are in the framework), thus I don't think the current > definitions serve any value. [/MB] > [SB] I agree with Mary that these definitions can simply be removed. [/SB] > >> >> 2. In REQMT-1d it is not clear what 'the extent of individual video >>> captures' means >>> >>> 3. In REQMT-2d it is not clear what 'the extent of individual audio >>> captures' means >>> >> >> We have had our own concerns about this. I think we want to say >> *something* but its unclear to me exactly what. Perhaps we could focus on >> what we want to use this for, and explicitly leave details of what it is >> for the FW. >> > [MB] Can you point to the threads of discussion where you feel this > concern with this phrasing has been raised? There were certainly concerns > raised about those requirements (i.e., 3D), but I'm not reading this as > Dan's concern. My understanding is that the word "extent" is used in the > context of video imagery from the perspective of the camera - i.e., the > "angular extent" or something like that. I think we should replace the > word "extent" with something more specific. Anyone have a suggestion? > [SB] The intent of REQMT-1d was to say that CLUE needs to identify the area that each camera captured in the room - so it would be clear how views from different camera related to each other, and also if there were any gaps, etc. Identifying the scale of the view is related, but is captured concisely in requirement 6. Proper rendering in a multi-camera telepresence system requires this knowledge - today it is generally hard-wired into the room design. But that doesn't result in an interoperable experience, and it needs to be signaled if you want to get appropriate rendering between rooms with disparate designs. For audio [REQMT-2d], there is an analogous need to identify the area of coverage of a microphone. The need to correlate the audio and the video is related, but is captured separately in REQMT-3. The discussions on the list related to audio and video area of coverage were about whether the model in the framework was adequate. Personally I believe it is. But what really matters here is whether we are clearly stating the *requirement*, not the adequacy of the proposed specifications. One alternative term is "area of coverage", which is commonly used in surveillance applications to describe a similar concept. If people think that might be confused with radio coverage (e.g. an LTE coverage map) we could draft a definition and add it to section 3. [/SB] > And, note these requirements were added based on discussion at IETF-82: > http://www.ietf.org/proceedings/82/slides/clue-1.pdf > > [/MB] > >> Thanks, >> Paul >> >> >> 4. REQMT-10: The solution MUST make it possible for endpoints without >>> support for telepresence extensions to participate in a >>> telepresence session with those that do. >>> >>> More clarity is needed to explain what level of participation in a >>> session (and what limitations) are expected from endpoints that do not >>> support the telepresence extensions. I assume there are limitations, >>> otherwise extensions would not be needed. >>> >> [SB] The intent was to simply state that the solution must not prevent direct interoperability with SIP devices (either phone or videoconferencing) - without the need for a middlebox to convert signaling (as would be required with rtcweb for instance). The limitation is simply that telepresence extensions can't be used. I do not see a need to describe the limitations of existing SIP systems in this requirements document. Suggested text that makes the requirement more clear would be helpful. This is a bit tricky to word, since SIP itself has no requirement that says SIP endpoints must interoperate with each other w/o middleboxes to assist. And in fact they often don't. We could alternatively drop the requirement. [/SB] > >>> 5. REQMT-15 (last bullet): I could not really figure out what is meant >>> here >>> >>> * There can be variation in placement, number and size of >>> presentations >>> >>> [SB]At this point I am not certain either. We might have meant that different use cases had different placements, number, and size of presentations. Or that existing telepresence systems handle presentations in different ways. It is not worded as a clear requirement, and it says "can", not "should" or "must". My recommendation is to delete that bullet. [/SB] > 6. REQMT-16: The solution MUST include extensibility mechanisms. >>> >>> What 'extensibility' is meant here? Extending the telepresence sessions, >>> or extending the specifications for new functionality in the future? >>> >> [SB] What is meant is extending the specifications for new functionality in the future. I suggest that we re-word to "New protocols developed for the solution MUST include extensibility mechanisms" [/SB] > >>> >>> Minor issues: >>> >>> 1. If this is the first and basic document to be read by somebody who >>> starts to browse through the CLUE specifications, it would be good to >>> define or expand some place in the introduction what CLUE is. >>> >>> [SB] I am not sure if the CLUE WG has a recommended order for reading the various documents. Personally I would recommend that people start with the use cases. In any event, I think the document purpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as an orientation to CLUE specifications. [/SB] > 2. In the Introduction Section I see: >>> >>> These >>>> >>> requirements are for the specification, they are not requirements on >>> the telepresence systems implementing the solution/protocol that will >>> be specified. >>> >>> But then all requirements in section 5 start by 'The solution ...' which >>> is ambiguous. It would be good to mention (again) in section 5 that by what >>> is meant by the 'solution' is the definition of the protocol, not the >>> implementation. >>> >> [SB] I agree. We should also use "specifications", since current plans call for more than one standards-track RFC [/SB] > >>> 3. I will defer to the Security Review to comment whether REQMT-18 is >>> enough from a security point of view - especially as the information about >>> media captures may include explicitly or implicitly details about equipment >>> on each site, etc. To me it seems a little bit too vague. >>> >> [SB] I don't see it as vague - it pretty clearly says that only the mechanism needs to be secure. I think you are saying that the security section might be incomplete. Current protocol designs do not include explicit details about equipment, and I see nothing in the requirements that suggest otherwise. Some requirements do require transport of information that can be used infer room dimensions (at least of the visible portion of the room) and the audio/video coverage within it. Can you identify threats that might use that information? Of course each specification includes its own Security Considerations. Obviously we will address any security review comments in this one. [/SB]. >>> Regards, >>> >>> Dan >>> >>> _______________________________________________ >>> 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 > > --001a11335afcc776a504ec301b87 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan - thanks so much for reviewing this.

Comments a= re in-line

Stephen Botzko

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@g= mail.com> wrote:
On Thu, Nov 2= 1, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Authors,

What do you think of these comments?
If you aren't in agreement with all of them, then we should have a dial= og with Dan about them.

If in agreement, then lets discuss what changes are appropriate.

More inline.


On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtf= aq>.

Please resolve these comments along with any other Last Call comments you m= ay receive.

Document: draft-ietf-clue-telepresence-requirements-06.txt
Reviewer: Dan Romascanu
Review Date: 11/21/13
IETF LC End Date: 11/27/13
IESG Telechat date: (if known)

Summary: It's a good and well written document, almost ready, but a num= ber of issues should be clarified before approval.

Major issues:

1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usa= ge of Wikipedia articles (subject to change, subject to attacks) as referen= ces, and I also believe that the current definitions (@11/21/13, US morning= hours) are ambiguous. Actually the Wikipedia article does not include defi= nitions for Left and Right, and speaks about 'house left' (equal to= 'stage right') and 'house right' (equal to 'stage left= '). If another specification in CLUE will use the terms defined here it= is not clear which one is meant.

This seems like a reasonable point to me. Is there a more stable reference = we can use? If not, can we just define these terms in the document?
[MB] I'm almost of a mind to just remove those definiti= ons. =A0The consensus was that the terms should be qualified when they are = used and the framework does an excellent job of defining more precise terms= that properly qualify "left" and "right" and different= iate from stage right, etc. as appropriate. =A0We use "left" and = "right" in one place in this requirements document and I think th= e use is general enough that we don't need a definition (in this docume= nt). =A0 The wikipedia reference has been in the document since day 1 as a = WG document (it was added in -03 of the individual document). =A0 The discu= ssions around "left"/"right" on the list were in the co= ntext of the definitions document and again, consensus was that the terms s= hould be qualified (as they are in the framework), thus I don't think t= he current definitions serve any value.=A0[/MB]=A0
[SB] I agree with Mary that these defin= itions can simply be removed.
[/SB]


2. In REQMT-1d it is not clear what 'the extent of individual video cap= tures' means

3. In REQMT-2d it is not clear what 'the extent of individual audio cap= tures' means

We have had our own concerns about this. I think we want to say *something*= but its unclear to me exactly what. Perhaps we could focus on what we want= to use this for, and explicitly leave details of what it is for the FW.
[MB] Can you point to the threads of discussion whe= re you feel this concern with this phrasing has been raised? =A0 There were= certainly concerns raised about those requirements (i.e., 3D), but I'm= not reading this as Dan's concern. =A0 My understanding is that the wo= rd "extent" is used in the context of video imagery from the pers= pective of the camera - i.e., the "angular extent" or something l= ike that. =A0I think we should replace the word "extent" with som= ething more specific. =A0Anyone have a suggestion?=A0
[SB]
The intent of REQMT-= 1d was to say that CLUE needs to identify the area that each camera capture= d in the room - so it would be clear how views from different camera relate= d to each other, and also if there were any gaps, etc.=A0 Identifying the s= cale of the view is related, but is captured concisely in requirement 6.=A0= Proper rendering in a multi-camera telepresence system requires this knowl= edge - today it is generally hard-wired into the room design.=A0 But that d= oesn't result in an interoperable experience, and it needs to be signal= ed if you want to get appropriate rendering between rooms with disparate de= signs.

For audio [REQMT-2d], there is an analogous need = to identify the area of coverage of a microphone.=A0 The need to correlate = the audio and the video is related, but is captured separately in REQMT-3.<= br>

The discussions on the list related to audio and = video area of coverage were about whether the model in the framework was ad= equate.=A0 Personally I believe it is.=A0 But what really matters here is w= hether we are clearly stating the requirement, not the adequacy of t= he proposed specifications.=A0

One alternative term is "area of coverage", which = is commonly used in surveillance applications to describe a similar concept= .=A0 If people think that might be confused with radio coverage (e.g. an LT= E coverage map) we could draft a definition and add it to section 3.
[/SB]


And, note these requirements were added based on discus= sion at IETF-82:
=A0=
=A0[/MB]
=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


4. REQMT-10: The solution MUST make it possible for endpoints without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support for telepresence extensions to parti= cipate in a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0telepresence session with those that do.

More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed.
[SB] The intent was to simply state that the solution must not p= revent direct interoperability with SIP devices (either phone or videoconfe= rencing) - without the need for a middlebox to convert signaling (as would = be required with rtcweb for instance). =A0 The limitation is simply that te= lepresence extensions can't be used.=A0 I do not see a need to describe= the limitations of existing SIP systems in this requirements document.=A0 =

Suggested text that makes the requirement more clear would be helpful.= =A0 This is a bit tricky to word, since SIP itself has no requirement that = says SIP endpoints must interoperate with each other w/o middleboxes to ass= ist. And in fact they often don't.=A0 We could alternatively drop the r= equirement.
[/SB]
<= div class=3D"gmail_extra">

5. REQMT-15 (last bullet): I could not really figure out what is meant here=

* =A0There can be variation in placement, number and size of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 presentations

[SB]At this point I am not certain either.=A0 We might have = meant that different use cases had different placements, number, and size o= f presentations. Or that existing telepresence systems handle presentations= in different ways.=A0

It is not worded as a clear requirement, and it says "can", n= ot "should" or "must".=A0 My recommendation is to delet= e that bullet.
[/SB]
6. REQMT-16: =A0The solution MUST include extensibility mechanisms.

What 'extensibility' is meant here? Extending the telepresence sess= ions, or extending the specifications for new functionality in the future?<= br>
[SB] What is meant is extending the specifications for ne= w functionality in the future.=A0 I suggest that we re-word to "New pr= otocols developed for the solution MUST include extensibility mechanisms&qu= ot;
[/SB]


Minor issues:

1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is.

[SB] I am not sure if the CLUE WG has a recommended order fo= r reading the various documents.=A0 Personally I would recommend that peopl= e start with the use cases.=A0 In any event, I think the document purpose i= s properly captured in the abstract - it is not intended to be an introduct= ion to telepresence generally or as an orientation to CLUE specifications.<= br> [/SB]
=A0
2. In the Introduction Section I see:

=A0 These
=A0 =A0 requirements are for the specification, they are not requirements o= n
=A0 =A0 the telepresence systems implementing the solution/protocol that wi= ll
=A0 =A0 be specified.

But then all requirements in section 5 start by 'The solution ...' = which is ambiguous. It would be good to mention (again) in section 5 that b= y what is meant by the 'solution' is the definition of the protocol= , not the implementation.
[SB] I agree.=A0 We should also use "specifications", = since current plans call for more than one standards-track RFC
[/SB]

3. I will defer to the Security Review to comment whether REQMT-18 is enoug= h from a security point of view - especially as the information about media= captures may include explicitly or implicitly details about equipment on e= ach site, etc. To me it seems a little bit too vague.
[SB] I don't see it as vague - it pretty clearly says that o= nly the mechanism needs to be secure.=A0 I think you are saying that the se= curity section might be incomplete.

Current protocol designs do not include explicit details about equipmen= t, and I see nothing in the requirements that suggest otherwise.=A0 Some re= quirements do require transport of information that can be used infer room = dimensions (at least of the visible portion of the room) and the audio/vide= o coverage within it.=A0 Can you identify threats that might use that infor= mation?=A0

Of course each specification includes its own Security Consi= derations. Obviously we will address any security review comments in this o= ne.
[/SB].



Regards,

Dan

_______________________________________________
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


--001a11335afcc776a504ec301b87-- From mary.ietf.barnes@gmail.com Fri Nov 29 13:17:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2AB1ADF99 for ; Fri, 29 Nov 2013 13:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB4FL4ua9g-I for ; Fri, 29 Nov 2013 13:17:03 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC991ADF6C for ; Fri, 29 Nov 2013 13:17:02 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so7345023wgh.32 for ; Fri, 29 Nov 2013 13:17:01 -0800 (PST) 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=/dAYu+wlHoHoBupi1C85+aKkMKguifMiGCGc+DIhpz4=; b=XcwNq2HiSvxGKyw3JWL83hdUyR6o8CsqnuH0qMlK2xJfGMtc0CkNwO+Eh/yLnpEm+k QWvsT/s01c7C2oISginFnQMRyygHgURimoDqkdJohUS52ClwlVmWqnwut6HlIRNW89wZ 0uZWOJ/2nf5CdtXzAQh9/B841IhnR4oN1DbLoGCa3XdkZBihd5YHS2yKvwgAJyXBXDWS MN+V6dwcMkejF9kX4m54ikgnVahQQ+dg01pCE2Vaz9Q3PGG3B7dRu6PdxWy67ZerGgPw 2viuASRB4/H02t+fun8PMjSMzSUbAlDRA+M41UD9dTU+uTmSIR7VdbIU+uqpK+scBv4E 92sg== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr8423765wic.36.1385759820865; Fri, 29 Nov 2013 13:17:00 -0800 (PST) Received: by 10.216.36.4 with HTTP; Fri, 29 Nov 2013 13:17:00 -0800 (PST) Date: Fri, 29 Nov 2013 15:17:00 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b624252dde63004ec57592f Subject: [clue] Minutes: CLUE WG Design Team meeting November, 26, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 29 Nov 2013 21:17:05 -0000 --047d7b624252dde63004ec57592f Content-Type: text/plain; charset=ISO-8859-1 Hi all, The minutes from this weeks design team meeting have been uploaded to the wiki: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-131126.txt The minutes contain a link to Rob's powerpoint presentation on the Encoding limits, as well as a link to the recording. There was consensus amongst those on the call that SDP should be used to express the encoding limits (as opposed to the CLUE protocol). We need to ensure that there is WG consensus for this approach, so I'll post a separate email on that topic. Thanks, Mary. --047d7b624252dde63004ec57592f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The minutes from this weeks des= ign team meeting have been uploaded to the wiki:

The minutes contain a link to Rob's pow= erpoint presentation on the Encoding limits, as well as a link to the recor= ding.

There was consensus amongst thos= e on the call that SDP should be used to express the encoding limits (as op= posed to the CLUE protocol). =A0We need to ensure that there is WG consensu= s for this approach, so I'll post a separate email on that topic.

Thanks,
Mary.=A0
--047d7b624252dde63004ec57592f-- From mary.ietf.barnes@gmail.com Fri Nov 29 13:24:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82B1AE009 for ; Fri, 29 Nov 2013 13:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0jSbdDt29bG for ; Fri, 29 Nov 2013 13:24:53 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2BC1ADF9B for ; Fri, 29 Nov 2013 13:24:53 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so7996870wgh.5 for ; Fri, 29 Nov 2013 13:24:51 -0800 (PST) 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=rgPlP3yE1v9ciCIt4Oprc9opPTLEZXMKLQBdsFIJesM=; b=VltiMLoAv7WsYR43egu1ZVZUXN/xBT9lHvblC7nhmlAdxW91ZIg98Ysd/FuOE20vFJ cAWQz/59/ATbWwtdYy78In53q23EDD8YLgppCOEolDJaR1YQk5++oTMCywoTu65f9qgS Xbof3QIY8f8fKCzV9euoQ3gfxcOynTLQ5FzjzW53KTVSU+mm4jT9SIHbnZFVg0HAlPO4 ksfeUPtcmQeaCwX3OxRuDfAolz0fDzzZWVdi11W9chnOx+hext9f6cZAbHrYDC7Bbx81 WzYQxcpblaP2o9OwxMB7f7M3iXLSgjanWFGGDWLVkzvBaJprl5nAoK9+VnwQd6ni7dnU 2qbQ== MIME-Version: 1.0 X-Received: by 10.180.74.45 with SMTP id q13mr8286739wiv.47.1385760291640; Fri, 29 Nov 2013 13:24:51 -0800 (PST) Received: by 10.216.36.4 with HTTP; Fri, 29 Nov 2013 13:24:51 -0800 (PST) Date: Fri, 29 Nov 2013 15:24:51 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043d676fed5b9f04ec5775be Subject: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 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, 29 Nov 2013 21:24:55 -0000 --f46d043d676fed5b9f04ec5775be Content-Type: text/plain; charset=ISO-8859-1 HI all, As mentioned in the email about the November 26th design team meeting, there was consensus amongst those on the call that SDP should be used for expressing encoding limits for CLUE. Rob's presentation had details as to how it could be done using the CLUE protocol, but it was decided (amongst those on the call) that we should go with the SDP approach for now and IF an issue is encountered with that approach as details are worked we could go back to the alternative proposal outlined in those charts. To move forward, we want to ensure that there is WG consensus for using SDP for the encoding limits. If anyone has any concerns about that approach, please post a note explaining why no later than Dec 9th, 2013. If you weren't at the design team meeting and would like to express your support for the approach, that's also a good idea. Regards, Mary As WG co-chair --f46d043d676fed5b9f04ec5775be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

As mentioned in the email about= the November 26th design team meeting, there was consensus amongst those o= n the call that SDP should be used for expressing encoding limits for CLUE.= =A0Rob's presentation had details as to how it could be done using the= CLUE protocol, but it was decided (amongst those on the call) that we shou= ld go with the SDP approach for now and IF an issue is encountered with tha= t approach as details are worked we could go back to the alternative propos= al outlined in those charts. =A0

To move forward, we want to ensure that there is = WG consensus for using SDP for the encoding limits. =A0If anyone has any co= ncerns about that approach, please post a note explaining why no later than= Dec 9th, 2013. =A0 If you weren't at the design team meeting and would= like to express your support for the approach, that's also a good idea= .=A0

Regards,
Mary
As WG co-chair
--f46d043d676fed5b9f04ec5775be--