From mary.ietf.barnes@gmail.com Thu Aug 1 01:26:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4C21F8BB7 for ; Thu, 1 Aug 2013 01:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 mKlTz5S5XRsU for ; Thu, 1 Aug 2013 01:26:46 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 16F4721F89D8 for ; Thu, 1 Aug 2013 01:26:40 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id i11so946033qej.5 for ; Thu, 01 Aug 2013 01:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3D1tuNb3MDrH9gMMU6r+cuPtJ1UoKKjOqT5o7x8oxN8=; b=gXZvy1qHGpLF6TZuBqfnsJkyyuchB5VBsQiKW8u4jbcZKE3nfeSPcPPlUTP+mCEGVr n86awcyHcVNJH9qBLDaAskp84xswoYNwGGoyLC/BfdBbY4mMIp8wQ3n0fBFjsYpUR5Qf MwnwWWfTVyK1zVvDM4eptW5crTiyQqdCi3E5q0hUnNGz7BtJUrAUYRp/vVgxW5Uo/ogC dkNPAvlvYey7gUF5k++/1+660hgviw/AOVNVrXb5eOaPJ3a+22Ta1lBEJ+loSctkDb3a tfvRS+SS8XQ6f8qDBQUEmYGbRYQC7fe5vgw63bH0L/QMF5iGC2cxprcioHEa6gPYldC9 n4Pg== MIME-Version: 1.0 X-Received: by 10.229.242.132 with SMTP id li4mr136264qcb.3.1375345600174; Thu, 01 Aug 2013 01:26:40 -0700 (PDT) Received: by 10.49.48.36 with HTTP; Thu, 1 Aug 2013 01:26:40 -0700 (PDT) In-Reply-To: <03FBA798AC24E3498B74F47FD082A92F3D844196@US70UWXCHMBA04.zam.alcatel-lucent.com> References: <51F06AB6.2010008@nostrum.com> <51F3F264.1040601@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C40D21C@ESESSMB209.ericsson.se> <51F4FAB5.2000507@jitsi.org> <7594FB04B1934943A5C02806D1A2204B1C412B01@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412B8C@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412CD3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C412D3F@ESESSMB209.ericsson.se> <51F78002.80102@alvestrand.no> <03FBA798AC24E3498B74F47FD082A92F3D844196@US70UWXCHMBA04.zam.alcatel-lucent.com> Date: Thu, 1 Aug 2013 03:26:40 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b676b44f1203c04e2de99f4 Subject: [clue] Fwd: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels 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, 01 Aug 2013 08:26:48 -0000 --047d7b676b44f1203c04e2de99f4 Content-Type: text/plain; charset=ISO-8859-1 Folks, This is the draft that was mentioned yesterday that may be informative for the CLUE usage of the RTCWEB data channel model. Mary. ---------- Forwarded message ---------- From: Ejzak, Richard P (Richard) Date: Tue, Jul 30, 2013 at 6:45 AM Subject: [MMUSIC] [rtcweb] [dispatch] bar BOF on msrp over DataChannels To: "mmusic@ietf.org" , "rtcweb@ietf.org" , "dispatch@ietf.org" As just mentioned in mmusic, we are organizing a bar BOF for Thursday at 6:30 PM in the Marlene Bar to discuss SDP aspects in http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels-00.txt. In particular, the draft includes SDP procedures to negotiate the use of any sub-protocol (e.g., msrp, bfcp, t140) over DataChannels (for sub-protocols that normally use SDP negotiation for other transport options). Some minimal additional sub-protocol specific procedures might also need to be specified. The draft also includes msrp-specific procedures needed for the transport of msrp over DataChannels. This proposal is intended to complement the current DataChannel procedures without requiring any browser support, which is why this work has not been raised directly in rtcweb. Please join us at the Marlene bar or let me know if you are interested but unable to participate. Thanks, Richard _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --047d7b676b44f1203c04e2de99f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks,=A0

This is the draft that was me= ntioned yesterday that may be informative for the CLUE usage of the RTCWEB = data channel model.

Mary.=A0

---------- Forwarded message ----------
From: Ejzak, Richard P (Richard) <richard.ejzak@alcatel-lucent.com><= /span>
Date: Tue, Jul 30, 2013 at 6:45 AM
Subject: [MMUSIC] [rtcweb] [dispatch= ] bar BOF on msrp over DataChannels
To: "mmusic@ietf.org" <m= music@ietf.org>, "rtcweb@iet= f.org" <rtcweb@ietf.org&= gt;, "dispatch@ietf.org"= <dispatch@ietf.org>


As just mentioned in mmusic, we are organizing a bar BOF for Thursd= ay at 6:30 PM in the Marlene Bar to discuss SDP aspects in http://www.ietf.org/internet-drafts/draft-marcon-= msrp-over-webrtc-data-channels-00.txt. =A0In particular, the draft incl= udes SDP procedures to negotiate the use of any sub-protocol (e.g., msrp, b= fcp, t140) over DataChannels (for sub-protocols that normally use SDP negot= iation for other transport options). =A0Some minimal additional sub-protoco= l specific procedures might also need to be specified. =A0The draft also in= cludes msrp-specific procedures needed for the transport of msrp over DataC= hannels.

This proposal is intended to complement the current DataChannel procedures = without requiring any browser support, which is why this work has not been = raised directly in rtcweb.

Please join us at the Marlene bar or let me know if you are interested but = unable to participate.

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

--047d7b676b44f1203c04e2de99f4-- From ietf@meetecho.com Thu Aug 1 02:06:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A5621F9E1A for ; Thu, 1 Aug 2013 02:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.136 X-Spam-Level: X-Spam-Status: No, score=0.136 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQsZ3Cwujtn9 for ; Thu, 1 Aug 2013 02:06:50 -0700 (PDT) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4D06121F8467 for ; Thu, 1 Aug 2013 02:06:26 -0700 (PDT) Received: from dell-tcastaldi ([130.129.65.11]) by smtpcmd02.ad.aruba.it with bizsmtp id 7M6L1m0120EaGCq01M6Maz; Thu, 01 Aug 2013 11:06:21 +0200 Date: Thu, 1 Aug 2013 11:06:18 +0200 (CEST) From: Meetecho Team To: clue@ietf.org Message-ID: <3885977.3.1375347978789.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2_1250771780.1375347978787" Subject: [clue] CLUE session recording available 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, 01 Aug 2013 09:06:55 -0000 ------=_Part_2_1250771780.1375347978787 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the CLUE WG session at IETF 87 is available at the following URL: http://ietf87.conf.meetecho.com/index.php/Recorded_Sessions#CLUE For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_2_1250771780.1375347978787-- From Mark.Duckworth@polycom.com Thu Aug 1 04:26:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1521E80C9 for ; Thu, 1 Aug 2013 04:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+mpnSYkS7nQ for ; Thu, 1 Aug 2013 04:26:09 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A57BE21E80D5 for ; Thu, 1 Aug 2013 04:25:56 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 1 Aug 2013 04:25:54 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 1 Aug 2013 04:25:51 -0700 Thread-Topic: [clue] draft-ietf-clue-data-model-schema-00 Thread-Index: Ac6M6dMj50oMbwYTTia+yj5Ajt7u0QBv47YQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60211E594@CRPMBOXPRD07.polycom.com> References: <51ED529F.8020504@alum.mit.edu> <51EDD134.20206@nteczone.com> <51EDEEE9.6030408@alum.mit.edu> <51EDFFC4.1090803@nteczone.com> <51EE6B77.2060601@unina.it> <51F1A34D.80400@alum.mit.edu> <51F20553.8030101@nteczone.com> <51F28FA7.5090603@alum.mit.edu> <51F5BB45.5010009@nteczone.com> <51F6DDE7.1070206@alum.mit.edu> <51F7006E.6040701@nteczone.com> <51F7557A.7050406@alum.mit.edu> In-Reply-To: <51F7557A.7050406@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] draft-ietf-clue-data-model-schema-00 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, 01 Aug 2013 11:26:14 -0000 I agree with using the value 0 for highest priority, and higher numbers mea= n lower priority, with default being lowest priority. I see no reason to make the range "user friendly for non-programmers". Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, July 30, 2013 7:56 AM > To: clue@ietf.org > Subject: Re: [clue] draft-ietf-clue-data-model-schema-00 >=20 > On 7/30/13 1:53 AM, Christian Groves wrote: > > Hello Paul, > > > > I'm thinking that this could be set by whoever is configuring the > > system at installation or at the start of a conference. Not something > > that is hard coded. So that's why I thought a more "user friendly" > > range would be good. Utilising 100, 101, 102, 200, 201, 202 etc... I > > think is more of a programmer's view on the world. I do the same thing > > when writing g-code for my mill but I'm not sure its a practise for > > telepresence endpoints. >=20 > If the goal is to make the *range* "user friendly" for non-programmers, t= hen > it ought to be some number of decimal digits rather than powers of two. >=20 > > It would be good to get other views on this. >=20 > Yep. >=20 > Thanks, > Paul >=20 > > Regards, Christian > > > > On 30/07/2013 7:25 AM, Paul Kyzivat wrote: > >> On 7/29/13 2:45 AM, Christian Groves wrote: > >>> Hello Paul, > >>> > >>> Please see below. > >>> > >>> Regards, Christian > >>> > >>> On 27/07/2013 1:03 AM, Paul Kyzivat wrote: > >>>> On 7/26/13 1:12 AM, Christian Groves wrote: > >>>> > >>>>> [CNG] Perhaps we should just make this a btye 0-255 possible > >>>>> values? And perhaps we need to say there is no inference to how > >>>>> much more important the priority based on the position. e.g. 1 is > >>>>> not 100x times more important than 100. If you have two captures > >>>>> one with priority 1 and the other priority 100 the priority one > >>>>> capture is simply more important. No difference to 1 & 2, 1 & 50 > >>>>> etc. > >>>> > >>>> Why would we want to restrict to 256 values? To save 3 bytes in the > >>>> implementation? > >>>> > >>>> While people can probably settle with that, why? > >>> > >>> [CNG] Its not to save the 3 bytes in signalling. I just think it is > >>> logically better to give a finite set of priorities within the > >>> realms of day to day experience. If I was to set this via some UI I > >>> think its easier present a range 0 - 256 rather than 0-2,147,483,647. > >> > >> I don't imagine a UI for setting these, at least not for regular > >> people. Do you? Its more conceivable that a UI for users might *show* > >> priorities. But then you only show the ones that were used. > >> > >> When I was looking at one example, I was thinking I would like to use > >> values like: > >> - 100, 101, 102, ... for one CSE or scene > >> - 200, 201, 202, ... for a different CSE or scene > >> > >> One can easily use up more than 256 that way. > >> > >> Another possibility is to use real numbers in range [0,1]. > >> > >> Then I can use 0.1, 0.2, ... or 0.10, 0.11, 0.12,... 0.20, 0.21, ... > >> and can in general stick something between any two I have previously > >> defined. > >> > >> Thanks, > >> Paul > >> > >>>>>> Implementations are going to need a representation for all > >>>>>> values, including the highest and lowest. > >>>>> [CNG] Strictly speaking we probably only need the "highest" priorit= y. > >>>>> The lowest is effectively the number before or after (depending on > >>>>> whether 1 is highest or not) those that have been set in the captur= es. > >>>> > >>>> The highest is zero, so that is easy. The lowest you can specify is > >>>> currently 2^32-1. Suppose somebody decides to set some captures to > >>>> 2^32-1, and leaves some unspecified? What value does the > >>>> implementation give to them? > >>>> > >>>> So just say the the default is 2^32-1, or maxint. XML allows you to > >>>> put a default in the schema. So we can just use that. > >>>> > >>>> This is assuming we want the default to be "lowest priority". If > >>>> the default is "highest priority" then of course it is zero. > >>> > >>> [CNG] I'm OK with Roberta's proposal: > >>> "the highest value =3D the first relevance rank (e.g. 1)" > >>> default lowest value 255. > >>>> > >>>>>> If we are to represent priorities as unsigned integers, then I > >>>>>> think both lowest and highest should fall into that range so that > >>>>>> the implementation can use an unsigned integer too. So *if* we > >>>>>> want the default to be lowest priority, then I would vote that we > >>>>>> make the default be the highest value representable in the range, > >>>>>> rather than something lower than that. > >>>>>> > >>>>>> I guess the question is whether we want the default to be highest > >>>>>> priority or lowest priority. > >>>>> [CNG] I think the "lowest priority". > >>>> > >>>> I don't much care. But I think it should be based on what we think > >>>> the most common case is. Will people want to just mark a few > >>>> captures as lower than the rest? Or just mark a few higher than the > rest? > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Aug 1 04:45:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C3E11E8122 for ; Thu, 1 Aug 2013 04:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 6zRmIViEpMsp for ; Thu, 1 Aug 2013 04:45:35 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2E11E8112 for ; Thu, 1 Aug 2013 04:45:35 -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; Thu, 1 Aug 2013 04:45:34 -0700 From: "Duckworth, Mark" To: "Robert Hansen (rohanse2)" , Roni Even , "clue@ietf.org" Date: Thu, 1 Aug 2013 04:45:32 -0700 Thread-Topic: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 Thread-Index: Ac6N/wr9ecuL2r5FTGWcBcW3HfT8egALcIawAB/BRDA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60211E598@CRPMBOXPRD07.polycom.com> References: <00f401ce8dff$58527960$08f76c20$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D60211E598CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 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, 01 Aug 2013 11:45:40 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60211E598CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Rob that this is a perfectly reasonable way to express Bob's a= bilities in the advertisement. But I also agree with Roni that the text is= misleading. Instead of: "Bob also has no simultaneity constraints, so includes all three captures i= n one simultaneous set." How about this: "Bob can send any combination of two video encodings, so includes all three= captures in one simultaneous set. The limit of two video encodings is exp= ressed in the encoding group that has only two individual encodings availab= le." Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Rob= ert Hansen (rohanse2) Sent: Wednesday, July 31, 2013 10:36 PM To: Roni Even; clue@ietf.org Subject: Re: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 Er, yes, my understanding was that this is correct behaviour. Bob is a two-= camera system and the implementation allows a maximum of two encodings to b= e sent. However, he has three captures he can send (the two static camera s= ources and the composed source). There are no simultaneity constraints with= any of these captures - sending any one doesn't prevent him sending anothe= r one, so all of them go in one simultaneous set. That seems correct by my understanding, as I though the primary point of si= multaneous sets was to prevent cases that are physically impossible (eg, Ev= e has the option for a capture that is a zoomed-in camera view, and other o= ption for a capture than is a zoomed-out view from the same camera - there'= s no way for her to do both simultaneously, which she will express by not i= ncluding them in the same simultaneous set). Rob From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 31 July 2013 17:05 To: clue@ietf.org Subject: [clue] draft-kyzivat-clue-signaling-04 - section 6 question 1 Hi, In the following paragraph the text says that Bob has no simultaneous const= rains and list all three captures but the advertisement have only to indivi= dual encodes so it look like he can send only two captures? "Bob also sends his CLUE Advertisement (ADVERTISEMENT 2). He advertises two static captures representing his cameras. He also includes a single composed capture for single-screen systems, in which he will composite the two camera views into a single video stream. All three captures are in a single capture scene, with suitable capture scene entries to tell Alice that she should either subscribe to the two static captures, or the single composed capture. Bob also has no simultaneity constraints, so includes all three captures in one simultaneous set. Bob also includes a single encoding group with two encoding IDs: "foo" and "bar"." Roni --_000_49E45C59CA48264997FEBFB29B6BC2D60211E598CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Rob that this is a perfectly reasonable way to e= xpress Bob’s abilities in the advertisement.  But I also agree w= ith Roni that the text is misleading.

 

Instead of:

“Bob also has no simu= ltaneity constraints, so includes all three captures in one simultaneous se= t.”

 

How about this:

“Bob can send any combination of two video en= codings, so includes all three captures in one simultaneous set.  The = limit of two video encodings is expressed in the encoding group that has on= ly two individual encodings available.”

 

Mark

 

From: clue-bounces@ietf.org [mail= to:clue-bounces@ietf.org] On Behalf Of Robert Hansen (rohanse2)
<= b>Sent: Wednesday, July 31, 2013 10:36 PM
To: Roni Even; clue= @ietf.org
Subject: Re: [clue] draft-kyzivat-clue-signaling-04 - s= ection 6 question 1

<= o:p> 

Er, yes, my understanding was that this is correct behaviour. Bob = is a two-camera system and the implementation allows a maximum of two encod= ings to be sent. However, he has three captures he can send (the two static= camera sources and the composed source). There are no simultaneity constra= ints with any of these captures – sending any one doesn’t preve= nt him sending another one, so all of them go in one simultaneous set.=

 

That seems correct by my understanding, as I though = the primary point of simultaneous sets was to prevent cases that are physic= ally impossible (eg, Eve has the option for a capture that is a zoomed-in c= amera view, and other option for a capture than is a zoomed-out view from t= he same camera – there’s no way for her to do both simultaneous= ly, which she will express by not including them in the same simultaneous s= et).

 

Rob

 

=

From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf Of Roni Even
Sent: 31 July 2013= 17:05
To: clue@ietf.org
Subject: [clue] draft-kyzivat-= clue-signaling-04 - section 6 question 1

<= p class=3DMsoNormal> 

Hi,

In the following paragra= ph the text says that Bob has no simultaneous constrains and list all three= captures but the advertisement have only to individual encodes so it look = like he can send only two captures?

<= o:p> 

“Bob also sends his CLUE = Advertisement (ADVERTISEMENT 2).  He

   advertises two static captures representing his cameras.&= nbsp; He also

   includes a= single composed capture for single-screen systems, in

   which he will composite the two camera views= into a single video

   st= ream.  All three captures are in a single capture scene, with

   suitable capture scene entries t= o tell Alice that she should either

&= nbsp;  subscribe to the two static captures, or the single composed ca= pture.

   Bob also has no s= imultaneity constraints, so includes all three

   captures in one simultaneous set.  Bob also inc= ludes a single

   encoding = group with two encoding IDs: "foo" and "bar".”

 

Roni

 

<= /div>
= --_000_49E45C59CA48264997FEBFB29B6BC2D60211E598CRPMBOXPRD07pol_-- From Christian.Groves@nteczone.com Sun Aug 11 19:27:50 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC6A11E810F for ; Sun, 11 Aug 2013 19:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y33vG-0aeWF6 for ; Sun, 11 Aug 2013 19:27:50 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 829D421E80BB for ; Sun, 11 Aug 2013 19:21:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8DAKxFCFJ20bdL/2dsb2JhbAANTYM7vxwEBIEybYJqGyU9FhgDAgECAUsNCAEBiBijZpFclFMDmRCTUg Received: from ppp118-209-183-75.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.183.75]) by ipmail04.adl6.internode.on.net with ESMTP; 12 Aug 2013 11:51:49 +0930 Message-ID: <520846B7.7020506@nteczone.com> Date: Mon, 12 Aug 2013 12:21:43 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Multiple Content Captures 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, 12 Aug 2013 02:27:50 -0000 Hello all, I've now posted my draft regarding switched / composed captures. http://datatracker.ietf.org/doc/draft-groves-clue-multi-content/ It's a discussion of the support of switching / composition in the current CLUE framework and highlights some of the issues. The main proposal (along with some clarifications) is a new type of capture the "multiple content capture" (MCC). The MCC references other captures e.g. video, audio and indicates the capture is made up of multiple audio and video captures. It enables the source information regarding the captures to be maintained. Regards, Christian From ron.even.tlv@gmail.com Mon Aug 19 06:21:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0092D21F9A44 for ; Mon, 19 Aug 2013 06:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7mgXEo7vki4 for ; Mon, 19 Aug 2013 06:21:36 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B55D021F99D2 for ; Mon, 19 Aug 2013 06:21:35 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hr7so3067741wib.4 for ; Mon, 19 Aug 2013 06:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=4VpHKVoMEtP4Q+o8ogVmR8Y384EDNyUDxzBfN2wTG28=; b=Q+qv+erfI7ZzGnUF7eXHq+wIijyxKpFF1An/auQ+zrsFPBEyldPICYE1C8B5yDIyVP +RHDEZFufyeu14Oo4yAPQr8UG2nKkhPe+dnoDsufiggDiflvIJWXsyLwjNCOQU6A9joP Ic9opyQsevVsk84LCvKSL7AS7NSbf8gGlR23yvQpl8mtKeb1v7d2K5vEFz57+MvPhXxM 30yzW20DvxmovsmY6y+4Eo0+14Tzy7YvHEnTtMJ+lgh5DPi35mC+BEDAVE1JWtHMqYAO EEPt2/sFTz9fbV5/2ppTL1D9zhpZvFzJjrwsthjTMoC6zbfXqwI1RwMtY9flfXWaTb2J js0w== X-Received: by 10.180.187.175 with SMTP id ft15mr8356125wic.20.1376918494866; Mon, 19 Aug 2013 06:21:34 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id v9sm16742033wiw.8.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Aug 2013 06:21:34 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <51DD0213.8000202@nteczone.com> In-Reply-To: <51DD0213.8000202@nteczone.com> Date: Mon, 19 Aug 2013 16:19:13 +0300 Message-ID: <016601ce9cde$b42724a0$1c756de0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGDFDtrUnI4suLGAzHfz/ZhFFB5ywJQ8426miEIZAA= Content-Language: en-us Subject: Re: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue-telepresence-use-cases-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 13:21:37 -0000 Hi Christian, Thanks, I am preparing an updated version to address your comments See inline Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Christian Groves > Sent: 10 July, 2013 9:41 AM > To: clue@ietf.org > Subject: Re: [clue] WGLC: http://www.ietf.org/id/draft-ietf-clue- > telepresence-use-cases-05.txt >=20 > Hello, >=20 > No problem with the draft going forward. I don't think there are any = major > issues. Some comments below: >=20 > Abstract: The first sentence seems a bit clunky. As a participant if = I'm sitting > somewhere I'm really present. Elsewhere telepresence has been defined = as: >=20 > " telepresence: An interactive audio-visual communications experience > between remote locations, where the users enjoy a strong sense of = realism > and presence between participants by optimizing a variety of = attributes such > as audio and video quality, eye contact, gaze awareness, body = language, > spatial audio, coordinated environments and natural image size." >=20 > Perhaps we can pick up the remote locations aspect? [Roni Even] Changed the text to=20 "Telepresence conferencing systems seek to create an environment that = gives non co-located users or user groups a feeling of co-located = presence through multimedia communication including at least audio and = video signals of high fidelity" >=20 >=20 > Section 2 1st para: Propose to insert a word, "We specifically do not = include in > our scenarios the <> infrastructure..." [Roni Even] OK >=20 > Section 2 2nd para: Propose to insert a word, "Microphones pick up = sound > and audio codec(s)<> produce one or..." [Roni Even] OK >=20 > Section 2 3rd para: Is the use of M, N and D needed? They're not used > anywhere else in the document. Also "content streams" is not used > elsewhere. Presentation stream appears to be the common term. Also the > word "back" could be removed ie. "...or playing a video for display". [Roni Even] changed the sentence taking out the M,N, D using one or = more instead. Changed content to presentation >=20 > Section 2 above list: Modify text " The fundamental parameters = describing > typical telepresence scenario<> include:" [Roni Even] OK >=20 > Section 2 list item 3: "Monitors" is broken into "main" and = "presentation" > should it be the same for "cameras"? [Roni Even] I think the current text is OK >=20 > Section 2 list item 6 (and general): The terms "screen", "display" and > "monitor" are all used interchangeably it would be good to use one = term. > Section 3 appears to use "screen". [Roni Even] change to "screen" in the document to be consistent with = framework >=20 > Section 2 list item 9: Could we just say "The number of primary = screens at > each site"? [Roni Even] OK >=20 > Section 2 list item 10: What is meant by =E2=80=9Ctype=E2=80=9D here? = Is it the type of > presentation or the type of monitor? [Roni Even] Type of monitor (screen) >=20 > Section 2 list item 12: "Viewpoint" Should we say "point of capture"? = In > general should we align the terminology where possible with the > framework? [Roni Even] OK >=20 > Section 2 list item 13: Would it be better to say "...fields or view = and how they > spatially relate to each other."? [Roni Even] OK >=20 > Section 2 Last paragraph: "spatial position of the speaker"... Should = this be > "microphone"? Speaker is a person, loudspeaker is the device. > Should check the draft to see that "loudspeaker" is used when a device = is > meant. [Roni Even] I think the text is correct. I changed in the first sentence = the word "display" to "render" >=20 > Section 2 Last paragraph: What is meant by "single-node" video = conferencing > unit? Node isn't used anywhere else in the draft. [Roni Even] Changed to single camera/screen=20 >=20 > Section 3 1st para: Could the first 2 sentences be removed or changed? = I take > it we won't be adding more use cases once WGLC is done? [Roni Even] Changed the first paragraph to " The use case scenarios focus on typical implementations. . There are a number of possible variants for these use cases, for example, the audio supported may differ at the end points (such as mono or stereo versus surround sound), etc." Also deleted the second paragraph. >=20 > Section 3.2 4th para: ", or put up the date" Is this needed? Putting = up a date > wouldn't maintain full size. [Roni Even] This is OK (see Mark's comment) just made the sentence = clearer >=20 > Section 3.5 2nd last para: "e. g." seems to have a large space. [Roni Even] OK >=20 > Section 3.6 1st para: modify "... panoramic views at all the = site<>." [Roni Even] OK >=20 > Section 3.7 1st para: typo "...and spatial layout of = p<>rticipants." [Roni Even] OK >=20 >=20 > Regards, Christian >=20 > On 9/07/2013 5:28 AM, Mary Barnes wrote: > > The chairs would like to start a 3 week WGLC for > > draft-ietf-clue-telepresence-use-cases-05. > > > > Please post your review comments, including an indication as to > > whether you believe the document is ready to progress, no later than > > Sunday, July 28th, 2013 24:00 UTC. > > > > Thanks, > > Mary. > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From internet-drafts@ietf.org Mon Aug 19 10:10:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311C211E8298; Mon, 19 Aug 2013 10:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, 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 rhUM+Yfq1ih3; Mon, 19 Aug 2013 10:10:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4467111E80DF; Mon, 19 Aug 2013 10:10:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819171006.18383.30573.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 10:10:06 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:10:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Filename : draft-ietf-clue-telepresence-use-cases-06.txt Pages : 17 Date : 2013-08-19 Abstract: Telepresence conferencing systems seek to create an environment that gives non co-located users or user groups a feeling of co-located presence through multimedia communication including at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Mon Aug 19 10:46:25 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 867A411E823D for ; Mon, 19 Aug 2013 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4WSsbjtBL9P for ; Mon, 19 Aug 2013 10:46:24 -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 7E0F211E8135 for ; Mon, 19 Aug 2013 10:46:24 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id en1so3329233wid.14 for ; Mon, 19 Aug 2013 10:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=9UehRUF/eQU9DTcHWLYhfoV+2Z/lqslJZaRvj1ztr88=; b=tRMBCVca8LuoqRbCXLLOA1k11tp5cPSlPazEZlEBY4Vid0cOg6dP8mlv4KzDzJB/C3 YEkXiMpEy2P2Lr9poRZaIhhrG+hRKkU6z6skjQzQxh78Ed4NIKe0loizLsJ8NFr3k3Vy MtNF0cqpPqFX0qGArXSGBGOfuvGcF1q1v6KyxXm0+g4XF0qR8r9A+A32PtuwIPzujmZt FUHfK3u1ZTKAN54DbPSLWYu0ec+xWpwXZLzeTLo6n4lEJYYxf+VZ6EPbvOHXcmdj/4VH yL5zLrkl42ZoIBc+CThsXcecaVbcKXySafALxkp5r5fWr+qf0C+iyCwz70mjgqj5PdMs 1y1A== X-Received: by 10.194.93.3 with SMTP id cq3mr9706432wjb.26.1376934383657; Mon, 19 Aug 2013 10:46:23 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id b13sm18389685wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 19 Aug 2013 10:46:22 -0700 (PDT) From: "Roni Even" To: , "Christian Groves" , "'Duckworth, Mark'" Date: Mon, 19 Aug 2013 20:43:51 +0300 Message-ID: <018301ce9d03$b2820050$178600f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0184_01CE9D1C.D7CF8670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6dA5ByfmhTRdniRTS1alstTD+ZLA== Content-Language: en-us Subject: [clue] New version of the use case drafts 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, 19 Aug 2013 17:46:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0184_01CE9D1C.D7CF8670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I updated the use case draft based on Christian and Mark's comments. I also addressed the comments on the list http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-06 So if the new version address their concerns it can be sent to publication Thanks Roni ------=_NextPart_000_0184_01CE9D1C.D7CF8670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I updated the = use case draft based on Christian and Mark’s comments. I also = addressed the comments on the list

http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-06=

So if the new version address = their concerns it can be sent to publication

Thanks

Roni

------=_NextPart_000_0184_01CE9D1C.D7CF8670-- From Christian.Groves@nteczone.com Mon Aug 19 17:08:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E583811E8186 for ; Mon, 19 Aug 2013 17:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k8xC3qBQBIz for ; Mon, 19 Aug 2013 17:08:21 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id D107711E817E for ; Mon, 19 Aug 2013 17:08:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAH+yElJ20dN0/2dsb2JhbAANTYM6wAWBOoMYAQEBBDIBBRslARALDgoJFg8JAwIBAgFFBg0BBwEBiBifMItAkFwHhBIDmRGTVg Received: from ppp118-209-211-116.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.211.116]) by ipmail07.adl2.internode.on.net with ESMTP; 20 Aug 2013 09:38:14 +0930 Message-ID: <5212B36A.6070203@nteczone.com> Date: Tue, 20 Aug 2013 10:08:10 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Roni Even References: <018301ce9d03$b2820050$178600f0$@gmail.com> In-Reply-To: <018301ce9d03$b2820050$178600f0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] New version of the use case drafts 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, 20 Aug 2013 00:08:22 -0000 Hello Roni, The updates address my comments. I'm happy for this to go forward. Christian On 20/08/2013 3:43 AM, Roni Even wrote: > > Hi, > > I updated the use case draft based on Christian and Mark’s comments. I > also addressed the comments on the list > > http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-06 > > So if the new version address their concerns it can be sent to publication > > Thanks > > Roni > From mary.ietf.barnes@gmail.com Thu Aug 22 15:28:01 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 27B4121F9CA4 for ; Thu, 22 Aug 2013 15:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 vyunjtTr1AOJ for ; Thu, 22 Aug 2013 15:28:00 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7390921F9C53 for ; Thu, 22 Aug 2013 15:28:00 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so1355567qcx.32 for ; Thu, 22 Aug 2013 15:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=talKFqeVIUi07xPE9OHrbIFmJCYcPVs0Gv0nyLYPhh4=; b=Zii6obbzDjP6Wh3b+2WevOZYqqXI60+WSi4f20NOY26KLFBZn136Pcr1Ylquh8S1Yl h9PgJZK150YoLl12pqSJpaZjMCH4eb3T3pvlK1VieoE3Yp3VxkJGqBsB5fmiEX5w9pI9 tLaOZLzt8kDx6cb3UQ8rn9HsFnsXE2mYDzWgjpUwl8O2WzBKFFrY9PW9BuMAN5jG5/Ox uU3nfnx5ve8aFhyWhnQACBShse8PKktv65Uee4qhGUH7VlgB1uLcHfXs1Mrb3D+xUnH2 86k8UdQwSQddpqTSYtPx5oUDFsPudbuPkli2sHxiqpP2RwTAnMtgdeN2Y980A5x8NdrV SYWw== MIME-Version: 1.0 X-Received: by 10.224.160.194 with SMTP id o2mr20972285qax.3.1377210479932; Thu, 22 Aug 2013 15:27:59 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 22 Aug 2013 15:27:59 -0700 (PDT) Date: Thu, 22 Aug 2013 17:27:59 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01536d7a6ff92504e490cdbd Subject: [clue] Revised IETF-87 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, 22 Aug 2013 22:28:01 -0000 --089e01536d7a6ff92504e490cdbd Content-Type: text/plain; charset=ISO-8859-1 I have uploaded a revised version of the minutes that includes a summary with conclusions/action items: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue If you have previously looked at the minutes you may need to refresh your browser to see the revised version. Please review and provide any comments or questions no later than August 30th, 2013. Note that there is a link to the Meetecho recording in the minutes - that is very helpful for remembering the discussions. Regards, Mary. --089e01536d7a6ff92504e490cdbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have uploaded a revised version of the minutes that incl= udes a summary with conclusions/action items:

If you have previously looked at the minutes you may ne= ed to refresh your browser to see the revised version.

Please review and provide any comments or questions no later than = August 30th, 2013. =A0 Note that there is a link to the Meetecho recording = in the minutes - that is very helpful for remembering the discussions.

Regards,
Mary.=A0
--089e01536d7a6ff92504e490cdbd-- From mary.ietf.barnes@gmail.com Thu Aug 22 15:42:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CA721F8E70 for ; Thu, 22 Aug 2013 15:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 KL0tUVydYwtV for ; Thu, 22 Aug 2013 15:42:48 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id DD53721F8E21 for ; Thu, 22 Aug 2013 15:42:47 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id p19so358895qcv.9 for ; Thu, 22 Aug 2013 15:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oCP8VBg35islS5gsdyZDAAc5DOVWo5n/WDkz0j01Row=; b=xxD9jHOtTNzp1TromrZYJLWOCmuF2DsMFLwS1NIcralCw1gRumTKxlqJEPmEw7thYz 1tpzasxkANnGzKd7FGwskmZApY+HE5hUBq44+ZbJRiQ3K5dK5FFlerfzAlNJZ8sS7VPJ aPsm//TNjZ8SWBrheS1M9stLvRXfEt6a9n8pqCIoz/vetgnvtANDSmOPt/ce9VB6KcSN bJyVAlzEmqK7VpmNgdZQkRhUI+yamX+KBewJL/nhiTWEV6IpDfJGI+75mB5aLADZZAcb mMeIlpHfFalAHQqA0J6KzRwfkZJSiap8mbp3lva78xU43Hq4jaSpBEiy5JzqGAVmlTC0 faQw== MIME-Version: 1.0 X-Received: by 10.224.161.144 with SMTP id r16mr19207063qax.86.1377211367375; Thu, 22 Aug 2013 15:42:47 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 22 Aug 2013 15:42:47 -0700 (PDT) In-Reply-To: <968728441.6671109.1377210816110.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <968728441.6671109.1377210816110.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Thu, 22 Aug 2013 17:42:47 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01537468554b7704e491027c 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, 22 Aug 2013 22:42:49 -0000 --089e01537468554b7704e491027c Content-Type: text/plain; charset=ISO-8859-1 HI all, Per discussions at IETF-87, we would like to schedule a virtual interim meeting before IETF-88. I have setup a doodle poll: http://doodle.com/sbz67fpa23gfrhca Please respond no later than Tuesday, August 27 5pm Central with your availability, so we can get the meeting on everyone's calendar. While there has been virtually no mailing list discussion since Berlin, Christian has submitted the document related to the issue on switched captures: http://tools.ietf.org/id/draft-groves-clue-multi-content-00.txt It would be really good for folks to review and comment on that so we can get that issue resolved. Note, that we also discussed restarting the weekly design team meetings, with the intent of focusing on the solution documents. The time slot we previously used was 10am Central. If that doesn't work for folks, please let myself and Paul know ASAP so we can possibly arrange another time. In particular if it doesn't work for those that volunteered to work on the solution issues: Simon, Christer H, Paul K, Roberta, Jonathan L, Rob H, Roni E. Thanks, Mary. --089e01537468554b7704e491027c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,=A0

Per discussions at IETF-87, = we would like to schedule a virtual interim meeting before IETF-88. =A0I ha= ve setup a doodle poll:
http://doodle.com/sbz67fp= a23gfrhca
=A0
Please respond no later than Tuesday, August 27 5pm Cent= ral with your availability, so we can get the meeting on everyone's cal= endar. =A0While there has been virtually no mailing list discussion since B= erlin, Christian has submitted the document related to the issue on switche= d captures:
It would be really good for folks to review and comment = on that so we can get that issue resolved.

Note, that we also discussed restarting the weekl= y design team meetings, with the intent of focusing on the solution documen= ts. =A0The time slot we previously used was 10am Central. =A0 If that doesn= 't work for folks, please let myself and Paul know ASAP so we can possi= bly arrange another time. =A0In particular if it doesn't work for those= that volunteered to work on the solution issues:=A0Simon, Christer H, Paul K, Roberta, Jonathan L, Rob H, Roni E.

Thanks,
Mary.
=


--089e01537468554b7704e491027c-- From trac+clue@trac.tools.ietf.org Mon Aug 26 10:53:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DBE11E81EC for ; Mon, 26 Aug 2013 10:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 oEHvR9DuX7Q2 for ; Mon, 26 Aug 2013 10:53:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA1511E81E4 for ; Mon, 26 Aug 2013 10:53:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:58476 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VE0yg-00017O-LY; Mon, 26 Aug 2013 19:53:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 26 Aug 2013 17:53:22 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/37#comment:1 Message-ID: <083.85cd1e7f1eb2eb838269152d5ae02513@trac.tools.ietf.org> References: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <068.c67c3cb3e7ab140f879422b8910486b8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@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: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130826175328.7EA1511E81E4@ietfa.amsl.com> Resent-Date: Mon, 26 Aug 2013 10:53:28 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #37: OPEN 1: Binaural Audio [REQMT-2C] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 17:53:29 -0000 #37: OPEN 1: Binaural Audio [REQMT-2C] Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This ticket is being closed per the mailing list proposal as there were no compelling reasons put forth as to why it needs to remain: http://www.ietf.org/mail-archive/web/clue/current/msg02753.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Mon Aug 26 11:42:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1E21F9B0D for ; Mon, 26 Aug 2013 11:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.561 X-Spam-Level: X-Spam-Status: No, score=-101.561 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_OBFU_Q1=0.227, 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 jxIFgAR41ng7 for ; Mon, 26 Aug 2013 11:42:20 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 16B5B21F9A72 for ; Mon, 26 Aug 2013 11:42:20 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id k5so1974809qej.22 for ; Mon, 26 Aug 2013 11:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J1koUoGXuS5ikV9w6SpKYnFN7xS4mfbze6LRhA2RgrE=; b=ErRZSKvsgp6KEEa4Hm2VqhDnSGkdlb8bVhqprypNCOyW2F9jED5MOLrcWrXulOTKji NuY7BemwSed2YaiiR00YKU+ncVodWq7WDbA0H3/JwFxCAt3nbix5nhrTs+lrWrk2gAbh zUF/Bv+I0bcoDoFV1mj3IITj1vwYtEga1zPN207VCl3XyNL0jjFcPzhpJl0tvaO3TYmm mnijJkKLvn4P30cIET7mn55yNWEmDNeFuETcn9Pt6CCYpSTjblF3klF8S9dd5I8iFD4k sGsP3MBnpzhe2qXOKhX3pHjVZy8TEwr4h+Ny+INxg3EN5VcLv6VS7wDlstcd2qP5JXmv DV5g== MIME-Version: 1.0 X-Received: by 10.224.114.11 with SMTP id c11mr18037669qaq.37.1377542539511; Mon, 26 Aug 2013 11:42:19 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Mon, 26 Aug 2013 11:42:19 -0700 (PDT) In-Reply-To: <51EF2044.3090308@nteczone.com> References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> <51EF2044.3090308@nteczone.com> Date: Mon, 26 Aug 2013 13:42:19 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=047d7bdc939cbb0d1104e4de1dd3 Cc: CLUE Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] 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, 26 Aug 2013 18:42:21 -0000 --047d7bdc939cbb0d1104e4de1dd3 Content-Type: text/plain; charset=ISO-8859-1 Christian, It wasn't clear to me whether you are agreeing or disagreeing with what I proposed. I was suggesting a very basic definition so that we can complete the requirements section. Are you suggesting an alternative to be included in the requirements document? I don't think we should have to wait for completion of the framework to complete the requirements. One thing I noticed is that the terms (and the text you have) are actually introduced in the use cases document as follows, so I don't think we need to re-iterate in other documents. We could easily add a reference to this specific section (3.3) of the use cases. And, actually, I think the right thing to do is to just add the reference to the "Multi-point meeting" use case as a reference to REQMT-13 and REQMT-14. One common policy is called site switching. Let's say the speaker is at site A and everyone else is at a "remote" site. When the room at site A shown, all the camera images from site A are forwarded to the remote sites. Therefore at each receiving remote site, all the screens display camera images from site A. This can be used to preserve full size image display, and also provide full visual context of the displayed far end, site A. In site switching, there is a fixed relation between the cameras in each room and the screens in remote rooms. The room or participants being shown is switched from time to time based on who is speaking or by manual control, e.g., from site A to site B. Segment switching is another policy choice. Still using site A as where the speaker is, and "remote" to refer to all the other sites, in segment switching, rather than sending all the images from site A, only the speaker at site A is shown. The camera images of the current speaker and previous speakers (if any) are forwarded to the other sites in the conference. Therefore the screens in each site are usually displaying images from different remote sites - the current speaker at site A and the previous ones. This strategy can be used to preserve full size image display, and also capture the non-verbal communication between the speakers. In segment switching, the display depends on the activity in the remote rooms - generally, but not necessarily based on audio / speech detection). Mary On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > Here's some text I've been working on with regards to the framework to > better describe site and segment switch. > > The "site-switch" policy means all captures are switched at the same time > to keep captures from the same endpoint site together. Let's say the > speaker is at site A and everyone else is at a "remote" site. > When the room at site A shown, all the camera images from site A are > forwarded to the remote sites. Therefore at each receiving remote site, all > the screens display camera images from site A. This can be used to preserve > full size image display, and also provide full visual context of the > displayed far end, site A. In site switching, there is a fixed relation > between the cameras in each room and the displays in remote rooms. The room > or participants being shown is switched from time to time based on who is > speaking or by manual control. > > The "segment-switch" policy means different captures can switch at > different times, and can be coming from different endpoints. Still using > site A as where the speaker is, and "remote" to refer to all the other > sites, in segment switching, rather than sending all the images from site > A, only the image containing the speaker at site A is shown. The camera > images of the current speaker and previous speakers (if any) are forwarded > to the other sites in the conference. > Therefore the screens in each site are usually displaying images from > different remote sites - the current speaker at site A and the previous > ones. This strategy can be used to preserve full size image display, and > also capture the non-verbal communication between the speakers. In segment > switching, the display depends on the activity in the remote rooms - > generally, but not necessarily based on audio / speech detection. > > Regards, Christian > > > On 24/07/2013 3:17 AM, Mary Barnes wrote: > >> My suggestion is to define the terms "site switching" and "segment >> switching" in this document using terminology consistent with this >> document. NOte, that these terms don't explicitly appear in the terminology >> section of the framework, however, they are clearly described in 6.2.2. So >> I think we can borrow some of that text and add a definition to the >> requirements document and close this issue. My suggestion is something like: >> >> Site-switching:there is a fixed relation between the cameras in each room >> and the displays in remote rooms. The room or participants being shown is >> switched from time to time based on who is speaking or by manual control. >> >> Segment-switching: there is a variable relation between the cameras in >> each room and the displays in different rooms. Rather than sending all the >> images from a room, only the image with the active speaker is sent from a >> specific room. Therefore the screens in each site are usually displaying >> images from different remote sites - the current speaker at site A and the >> previous ones. >> >> Please make suggestions if you have alternative wording. I'd like to get >> this issue closed no later than August 12, 2013. >> >> Thanks, >> Mary. >> >> >> On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker < >> trac+clue@trac.tools.ietf.org >> >> wrote: >> >> #39: OPEN-3 Conference modes [REQMT-14] >> >> This wording of this requirement >> is problematic in part because the conference modes (site >> switching and segment switching) are not defined. It at >> least needs rewording. This is deferred until broader >> discussion on layout is concluded. >> >> -- >> ------------------------------**-------+----------------------** >> --------------- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com > >> | >> telepresence- >> Type: defect | requirements@tools.ietf.org >> > >> >> Priority: major | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------**-------+----------------------** >> --------------- >> >> Ticket URL: >> > >> 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 > --047d7bdc939cbb0d1104e4de1dd3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Christian,

It wasn't clear to me wh= ether you are agreeing or disagreeing with what I proposed. =A0I was sugges= ting a very basic definition so that we can complete the requirements secti= on. Are you suggesting an alternative to be included in the requirements do= cument? =A0 =A0I don't think we should have to wait for completion of t= he framework to complete the requirements. =A0

One thing I noticed is that the terms (and the text you= have) are actually introduced in the use cases document as follows, so I d= on't think we need to re-iterate in other documents. =A0We could easily= add a reference to this specific section (3.3) of the use cases. =A0And, a= ctually, I think the right thing to do is to just add the reference to the = "Multi-point meeting" use case as a reference to REQMT-13 and REQ= MT-14.=A0
   One co=
mmon policy is called site switching.  Let's say the speaker is
   at site A and everyone else is at a "remote" site.  When the r=
oom at
   site A shown, all the camera images from site A are forwarded to the
   remote sites.  Therefore at each receiving remote site, all the
   screens display camera images from site A.  This can be used to
   preserve full size image display, and also provide full visual
   context of the displayed far end, site A.  In site switching, there
   is a fixed relation between the cameras in each room and the screens
   in remote rooms.  The room or participants being shown is switched
   from time to time based on who is speaking or by manual control,
   e.g., from site A to site B.

   Segment switching is another policy choice.  Still using site A as
   where the speaker is, and "remote" to refer to all the other s=
ites,
   in segment switching, rather than sending all the images from site A,
   only the speaker at site A is shown.  The camera images of the
   current speaker and previous speakers (if any) are forwarded to the
   other sites in the conference.  Therefore the screens in each site
   are usually displaying images from different remote sites - the
   current speaker at site A and the previous ones.  This strategy can
   be used to preserve full size image display, and also capture the
   non-verbal communication between the speakers.  In segment switching,
   the display depends on the activity in the remote rooms - generally,
   but not necessarily based on audio / speech detection).
Mary

On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Mary,

Here's some text I've been working on with regards to the framework= to better describe site and segment switch.

The "site-switch" policy means all captures are switched at the s= ame time to keep captures from the same endpoint site together. Let's s= ay the speaker is at site A and everyone else is at a "remote" si= te.
When the room at site A shown, all the camera images from site A are forwar= ded to the remote sites. Therefore at each receiving remote site, all the s= creens display camera images from site A. This can be used to preserve full= size image display, and also provide full visual context of the displayed = far end, site A. In site switching, there is a fixed relation between the c= ameras in each room and the displays in remote rooms. The room or participa= nts being shown is switched from time to time based on who is speaking or b= y manual control.

The "segment-switch" policy means different captures can switch a= t different times, and can be coming from different endpoints. Still using = site A as where the speaker is, and "remote" to refer to all the = other sites, in segment switching, rather than sending all the images from = site A, only the image containing the speaker at site A is shown. The camer= a images of the current speaker and previous speakers (if any) are forwarde= d to the other sites in the conference.
Therefore the screens in each site are usually displaying images from diffe= rent remote sites - the current speaker at site A and the previous ones. Th= is strategy can be used to preserve full size image display, and also captu= re the non-verbal communication between the speakers. In segment switching,= the display depends on the activity in the remote rooms - generally, but n= ot necessarily based on audio / speech detection.

Regards, Christian


On 24/07/2013 3:17 AM, Mary Barnes wrote:
My suggestion is to define the terms "site switching" and "s= egment switching" in this document using terminology consistent with t= his document. NOte, that these terms don't explicitly appear in the ter= minology section of the framework, however, they are clearly described in 6= .2.2. So I think we can borrow some of that text and add a definition to th= e requirements document and close this issue. My suggestion is something li= ke:

Site-switching:there is a fixed relation between the cameras in each room a= nd the displays in remote rooms. The room or participants being shown is sw= itched from time to time based on who is speaking or by manual control.

Segment-switching: there is a variable relation between the cameras in each= room and the displays in different rooms. Rather than sending all the imag= es from a room, only the image with the active speaker is sent from a speci= fic room. Therefore the screens in each site are usually displaying images = from different remote sites - the current speaker at site A and the previou= s ones.

Please make suggestions if you have alternative wording. I'd like to ge= t this issue closed no later than August 12, 2013.

Thanks,
Mary.


On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker <trac+clue@trac.tools.iet= f.org <mailto:trac+clue@trac.tools.ietf.org>> wrote:

=A0 =A0 #39: OPEN-3 Conference modes [REQMT-14]

=A0 =A0 This wording of this requirement
=A0 =A0 is problematic in part because the conference modes (site
=A0 =A0 switching and segment switching) are not defined. It at
=A0 =A0 least needs rewording. This is deferred until broader
=A0 =A0 discussion on layout is concluded.

=A0 =A0 --
=A0 =A0 -------------------------------------+----------------------= ---------------
=A0 =A0 Reporter: | Owner: draft-ietf-clue-
=A0 =A0 mar= y.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com> |
=A0 =A0 telepresence-
=A0 =A0 Type: defect | requirements@tools.ietf.org
=A0 =A0 <mailto:requirements@tools.ietf.org>

=A0 =A0 Priority: major | Status: new
=A0 =A0 Component: telepresence- | Milestone: milestone1
=A0 =A0 requirements | Version:
=A0 =A0 Severity: Active WG Document | Keywords:
=A0 =A0 -------------------------------------+----------------------= ---------------

=A0 =A0 Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac= /ticket/39>
=A0 =A0 clue <http://tools.ietf.org/wg/clue/>




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

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

--047d7bdc939cbb0d1104e4de1dd3-- From trac+clue@trac.tools.ietf.org Mon Aug 26 11:55:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB4B21F9F6F for ; Mon, 26 Aug 2013 11:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, 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 q4rrgMfoCDo5 for ; Mon, 26 Aug 2013 11:55:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45021F9EA9 for ; Mon, 26 Aug 2013 11:55:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:34552 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VE1wX-0001LE-2t; Mon, 26 Aug 2013 20:55:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 26 Aug 2013 18:55:13 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/40#comment:1 Message-ID: <083.2be46fb66a32dab5a9aa8659d3c5ac3a@trac.tools.ietf.org> References: <068.a8190a00ee0b53b4b9ba1ca7a491ddb0@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <068.a8190a00ee0b53b4b9ba1ca7a491ddb0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@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: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130826185517.1F45021F9EA9@ietfa.amsl.com> Resent-Date: Mon, 26 Aug 2013 11:55:16 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #40: OPEN-4 New Requirement - attribute changes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:55:21 -0000 #40: OPEN-4 New Requirement - attribute changes Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This was an issue discussed in the -01 that was actually resolved in the -02 (i.e., the issue should have been removed from the appendix in the -02): http://www.ietf.org/mail-archive/web/clue/current/msg02749.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: task | requirements@tools.ietf.org Priority: minor | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 26 11:59: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 3D84621F8FDC for ; Mon, 26 Aug 2013 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 J+rD3JiUXTD8 for ; Mon, 26 Aug 2013 11:59:09 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53F21F8E2A for ; Mon, 26 Aug 2013 11:59:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:34837 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VE20H-0000sY-Up; Mon, 26 Aug 2013 20:59:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 26 Aug 2013 18:59:05 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/41#comment:2 Message-ID: <083.c1afb1bb82df98eca00b2efabd7595ba@trac.tools.ietf.org> References: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <068.45aa03fdb161ad1212283fd52f6bb700@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@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: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130826185909.9B53F21F8E2A@ietfa.amsl.com> Resent-Date: Mon, 26 Aug 2013 11:59:09 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #41: OPEN-5. New Requirement - 3D X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 18:59:10 -0000 #41: OPEN-5. New Requirement - 3D Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was actually resolved in the -02 version of the document: http://www.ietf.org/mail-archive/web/clue/current/msg02763.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Aug 26 12:01:33 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 581DA11E821B for ; Mon, 26 Aug 2013 12:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 xJt6MCdi2Uxc for ; Mon, 26 Aug 2013 12:01:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBA11E824C for ; Mon, 26 Aug 2013 12:01:23 -0700 (PDT) Received: from localhost ([127.0.0.1]:35028 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VE22R-0005UO-1r; Mon, 26 Aug 2013 21:01:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, ron.even.tlv@gmail.com, stephen.botzko@gmail.com X-Trac-Project: clue Date: Mon, 26 Aug 2013 19:01:19 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/42#comment:5 Message-ID: <083.4a5e7c439567771bced6957f27a84876@trac.tools.ietf.org> References: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <068.7d46c925fa3817ec28e58b9f6eba8120@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, ron.even.tlv@gmail.com, stephen.botzko@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: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130826190123.9AEBA11E824C@ietfa.amsl.com> Resent-Date: Mon, 26 Aug 2013 12:01:23 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #42: OPEN-6. Multi-view X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 19:01:33 -0000 #42: OPEN-6. Multi-view Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: minor | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From Christian.Groves@nteczone.com Mon Aug 26 18:08: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 CE8C711E8118 for ; Mon, 26 Aug 2013 18:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 wwxn-jW+6P36 for ; Mon, 26 Aug 2013 18:08:10 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0A611E810F for ; Mon, 26 Aug 2013 18:08:09 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAFP7G1J20cWg/2dsb2JhbAANTYM8wHSBOYMYAQEBAwEBAQE1GxUGBAYBBQsLGAkWCAcJAwIBAgEPBh8RBg0BBQIBAReHVAMJEqRQiTsNiWqNf4FJgS8HhBkDlgWDFosIiFw Received: from ppp118-209-197-160.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.197.160]) by ipmail07.adl2.internode.on.net with ESMTP; 27 Aug 2013 10:38:01 +0930 Message-ID: <521BFBEA.8060804@nteczone.com> Date: Tue, 27 Aug 2013 11:07:54 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> <51EF2044.3090308@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] 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, 27 Aug 2013 01:08:10 -0000 Hello Mary, I was making a comment to stimulate discussion. If we want to finish the requirements document without referring to the other documents e.g. the use cases or framework we should avoid using these terms. It would mean that we just need to update REQ-14: REQMT-14: The solution MUST support mechanisms to make possible for either or both site switching or segment switching. [Edt: This needs rewording. Deferred until layout discussion is resolved.] I propose rewording to: REQMT-14: The solution MUST support mechanisms to allow media from one source endpoint or/and multiple source endpoints to be sent to a remote endpoint at a particular point in time. Which media is sent at a point in time may be based on local policy. I think we just need to focus on the "source" and "time" aspect rather than the relation between camera and displays. The display aspect is up to the local policy of the receiving endpoint. Regards, Christian On 27/08/2013 4:42 AM, Mary Barnes wrote: > Christian, > > It wasn't clear to me whether you are agreeing or disagreeing with > what I proposed. I was suggesting a very basic definition so that we > can complete the requirements section. Are you suggesting an > alternative to be included in the requirements document? I don't > think we should have to wait for completion of the framework to > complete the requirements. > > One thing I noticed is that the terms (and the text you have) are > actually introduced in the use cases document as follows, so I don't > think we need to re-iterate in other documents. We could easily add a > reference to this specific section (3.3) of the use cases. And, > actually, I think the right thing to do is to just add the reference > to the "Multi-point meeting" use case as a reference to REQMT-13 and > REQMT-14. > One common policy is called site switching. Let's say the speaker is > at site A and everyone else is at a "remote" site. When the room at > site A shown, all the camera images from site A are forwarded to the > remote sites. Therefore at each receiving remote site, all the > screens display camera images from site A. This can be used to > preserve full size image display, and also provide full visual > context of the displayed far end, site A. In site switching, there > is a fixed relation between the cameras in each room and the screens > in remote rooms. The room or participants being shown is switched > from time to time based on who is speaking or by manual control, > e.g., from site A to site B. > > Segment switching is another policy choice. Still using site A as > where the speaker is, and "remote" to refer to all the other sites, > in segment switching, rather than sending all the images from site A, > only the speaker at site A is shown. The camera images of the > current speaker and previous speakers (if any) are forwarded to the > other sites in the conference. Therefore the screens in each site > are usually displaying images from different remote sites - the > current speaker at site A and the previous ones. This strategy can > be used to preserve full size image display, and also capture the > non-verbal communication between the speakers. In segment switching, > the display depends on the activity in the remote rooms - generally, > but not necessarily based on audio / speech detection). > Mary > > On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves > > > wrote: > > Hello Mary, > > Here's some text I've been working on with regards to the > framework to better describe site and segment switch. > > The "site-switch" policy means all captures are switched at the > same time to keep captures from the same endpoint site together. > Let's say the speaker is at site A and everyone else is at a > "remote" site. > When the room at site A shown, all the camera images from site A > are forwarded to the remote sites. Therefore at each receiving > remote site, all the screens display camera images from site A. > This can be used to preserve full size image display, and also > provide full visual context of the displayed far end, site A. In > site switching, there is a fixed relation between the cameras in > each room and the displays in remote rooms. The room or > participants being shown is switched from time to time based on > who is speaking or by manual control. > > The "segment-switch" policy means different captures can switch at > different times, and can be coming from different endpoints. Still > using site A as where the speaker is, and "remote" to refer to all > the other sites, in segment switching, rather than sending all the > images from site A, only the image containing the speaker at site > A is shown. The camera images of the current speaker and previous > speakers (if any) are forwarded to the other sites in the conference. > Therefore the screens in each site are usually displaying images > from different remote sites - the current speaker at site A and > the previous ones. This strategy can be used to preserve full size > image display, and also capture the non-verbal communication > between the speakers. In segment switching, the display depends on > the activity in the remote rooms - generally, but not necessarily > based on audio / speech detection. > > Regards, Christian > > > On 24/07/2013 3:17 AM, Mary Barnes wrote: > > My suggestion is to define the terms "site switching" and > "segment switching" in this document using terminology > consistent with this document. NOte, that these terms don't > explicitly appear in the terminology section of the framework, > however, they are clearly described in 6.2.2. So I think we > can borrow some of that text and add a definition to the > requirements document and close this issue. My suggestion is > something like: > > Site-switching:there is a fixed relation between the cameras > in each room and the displays in remote rooms. The room or > participants being shown is switched from time to time based > on who is speaking or by manual control. > > Segment-switching: there is a variable relation between the > cameras in each room and the displays in different rooms. > Rather than sending all the images from a room, only the image > with the active speaker is sent from a specific room. > Therefore the screens in each site are usually displaying > images from different remote sites - the current speaker at > site A and the previous ones. > > Please make suggestions if you have alternative wording. I'd > like to get this issue closed no later than August 12, 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker > > >> wrote: > > #39: OPEN-3 Conference modes [REQMT-14] > > This wording of this requirement > is problematic in part because the conference modes (site > switching and segment switching) are not defined. It at > least needs rewording. This is deferred until broader > discussion on layout is concluded. > > -- > > -------------------------------------+------------------------------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com > > | > telepresence- > Type: defect | requirements@tools.ietf.org > > > > > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > > -------------------------------------+------------------------------------- > > Ticket URL: > > clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From mary.ietf.barnes@gmail.com Tue Aug 27 06:35:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A1021E804D for ; Tue, 27 Aug 2013 06:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, SARE_SUB_OBFU_Q1=0.227, 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 tgGS6IZUttaU for ; Tue, 27 Aug 2013 06:35:19 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EAA0511E8339 for ; Tue, 27 Aug 2013 06:35:18 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id m4so2571280qcy.34 for ; Tue, 27 Aug 2013 06:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WAThAz7fQRTudQHzI4eNnoRksdpwM9k3IcG5U60dfb8=; b=Tovi1YaiMEQwMJz1x2rPgxpnOMzOM2r4upKC9/QweoeMOWlXKnox0lp8q1nyx7AoZ8 Fyr3vFlHa5FnJGNYKjTf0y3BHE4zCaeZCeb22iSnYup7fwF5bVlBTfkSppEXsm3DndWz b4+nhPPlrBJSzaenHwZC6ZbMb03z8JaOKxF6ZBDLQvxrjo//OqpfaVlno8nuSmkLD3mQ cc0CtVbcHTnBmmD81WFEn3SUwRR8eRIjWuugxe8+SIoVQGjsKX7bX8EXY+dczg8o/mlQ AlZrv3cPPIeNXE5+YXFf11Q+f5m20ogx2YI9FfwOR8OPjRXkvjCx/umsxA0tTozxa1Bv myXA== MIME-Version: 1.0 X-Received: by 10.224.126.129 with SMTP id c1mr2068514qas.93.1377610518346; Tue, 27 Aug 2013 06:35:18 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 27 Aug 2013 06:35:18 -0700 (PDT) In-Reply-To: <521BFBEA.8060804@nteczone.com> References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> <51EF2044.3090308@nteczone.com> <521BFBEA.8060804@nteczone.com> Date: Tue, 27 Aug 2013 08:35:18 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c2e32895c17304e4edf10b Cc: CLUE Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] 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, 27 Aug 2013 13:35:21 -0000 --001a11c2e32895c17304e4edf10b Content-Type: text/plain; charset=ISO-8859-1 Hi Christian, Thanks for the proposal. My comments are below. For the WG, we really need feedback from other folks on how to handle this requirement. This is the only remaining open issue for the requirements document. Mary. On Mon, Aug 26, 2013 at 8:07 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > I was making a comment to stimulate discussion. If we want to finish the > requirements document without referring to the other documents e.g. the use > cases or framework we should avoid using these terms. [MB] Actually, the requirements absolutely should refer to the use cases. There are references to many of the use cases referenced in the requirements. [/MB] > It would mean that we just need to update REQ-14: > > REQMT-14: The solution MUST support mechanisms to make possible for > either or both site switching or segment switching. [Edt: > This needs rewording. Deferred until layout discussion is > resolved.] > > I propose rewording to: > > REQMT-14: The solution MUST support mechanisms to allow media from one > source endpoint or/and multiple source endpoints to be sent to a remote > endpoint at a particular point in time. Which media is sent at a point in > time may be based on local policy. > [MB] I'd like to hear from others, but personally, I think that the requirement stated as is is okay if we add the reference to section 3.3 to the requirement. However, I have no issues with your proposal either. [/MB] > > I think we just need to focus on the "source" and "time" aspect rather > than the relation between camera and displays. The display aspect is up to > the local policy of the receiving endpoint. > > Regards, Christian > > > On 27/08/2013 4:42 AM, Mary Barnes wrote: > >> Christian, >> >> It wasn't clear to me whether you are agreeing or disagreeing with what I >> proposed. I was suggesting a very basic definition so that we can complete >> the requirements section. Are you suggesting an alternative to be included >> in the requirements document? I don't think we should have to wait for >> completion of the framework to complete the requirements. >> >> One thing I noticed is that the terms (and the text you have) are >> actually introduced in the use cases document as follows, so I don't think >> we need to re-iterate in other documents. We could easily add a reference >> to this specific section (3.3) of the use cases. And, actually, I think >> the right thing to do is to just add the reference to the "Multi-point >> meeting" use case as a reference to REQMT-13 and REQMT-14. >> One common policy is called site switching. Let's say the speaker is >> at site A and everyone else is at a "remote" site. When the room at >> site A shown, all the camera images from site A are forwarded to the >> remote sites. Therefore at each receiving remote site, all the >> screens display camera images from site A. This can be used to >> preserve full size image display, and also provide full visual >> context of the displayed far end, site A. In site switching, there >> is a fixed relation between the cameras in each room and the screens >> in remote rooms. The room or participants being shown is switched >> from time to time based on who is speaking or by manual control, >> e.g., from site A to site B. >> >> Segment switching is another policy choice. Still using site A as >> where the speaker is, and "remote" to refer to all the other sites, >> in segment switching, rather than sending all the images from site A, >> only the speaker at site A is shown. The camera images of the >> current speaker and previous speakers (if any) are forwarded to the >> other sites in the conference. Therefore the screens in each site >> are usually displaying images from different remote sites - the >> current speaker at site A and the previous ones. This strategy can >> be used to preserve full size image display, and also capture the >> non-verbal communication between the speakers. In segment switching, >> the display depends on the activity in the remote rooms - generally, >> but not necessarily based on audio / speech detection). >> Mary >> >> On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves < >> Christian.Groves@nteczone.com >> >> wrote: >> >> Hello Mary, >> >> Here's some text I've been working on with regards to the >> framework to better describe site and segment switch. >> >> The "site-switch" policy means all captures are switched at the >> same time to keep captures from the same endpoint site together. >> Let's say the speaker is at site A and everyone else is at a >> "remote" site. >> When the room at site A shown, all the camera images from site A >> are forwarded to the remote sites. Therefore at each receiving >> remote site, all the screens display camera images from site A. >> This can be used to preserve full size image display, and also >> provide full visual context of the displayed far end, site A. In >> site switching, there is a fixed relation between the cameras in >> each room and the displays in remote rooms. The room or >> participants being shown is switched from time to time based on >> who is speaking or by manual control. >> >> The "segment-switch" policy means different captures can switch at >> different times, and can be coming from different endpoints. Still >> using site A as where the speaker is, and "remote" to refer to all >> the other sites, in segment switching, rather than sending all the >> images from site A, only the image containing the speaker at site >> A is shown. The camera images of the current speaker and previous >> speakers (if any) are forwarded to the other sites in the conference. >> Therefore the screens in each site are usually displaying images >> from different remote sites - the current speaker at site A and >> the previous ones. This strategy can be used to preserve full size >> image display, and also capture the non-verbal communication >> between the speakers. In segment switching, the display depends on >> the activity in the remote rooms - generally, but not necessarily >> based on audio / speech detection. >> >> Regards, Christian >> >> >> On 24/07/2013 3:17 AM, Mary Barnes wrote: >> >> My suggestion is to define the terms "site switching" and >> "segment switching" in this document using terminology >> consistent with this document. NOte, that these terms don't >> explicitly appear in the terminology section of the framework, >> however, they are clearly described in 6.2.2. So I think we >> can borrow some of that text and add a definition to the >> requirements document and close this issue. My suggestion is >> something like: >> >> Site-switching:there is a fixed relation between the cameras >> in each room and the displays in remote rooms. The room or >> participants being shown is switched from time to time based >> on who is speaking or by manual control. >> >> Segment-switching: there is a variable relation between the >> cameras in each room and the displays in different rooms. >> Rather than sending all the images from a room, only the image >> with the active speaker is sent from a specific room. >> Therefore the screens in each site are usually displaying >> images from different remote sites - the current speaker at >> site A and the previous ones. >> >> Please make suggestions if you have alternative wording. I'd >> like to get this issue closed no later than August 12, 2013. >> >> Thanks, >> Mary. >> >> >> On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker >> > >> > >> >> >> >>> >> wrote: >> >> #39: OPEN-3 Conference modes [REQMT-14] >> >> This wording of this requirement >> is problematic in part because the conference modes (site >> switching and segment switching) are not defined. It at >> least needs rewording. This is deferred until broader >> discussion on layout is concluded. >> >> -- >> ------------------------------** >> -------+----------------------**--------------- >> Reporter: | Owner: draft-ietf-clue- >> mary.ietf.barnes@gmail.com >> > >> >> >> >> >> | >> telepresence- >> Type: defect | requirements@tools.ietf.org >> >> > >> >> >> >> >> >> >> Priority: major | Status: new >> Component: telepresence- | Milestone: milestone1 >> requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------** >> -------+----------------------**--------------- >> >> Ticket URL: >> >> > >> 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 >> >> >> > --001a11c2e32895c17304e4edf10b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christian,

Thanks for the proposal. = =A0My comments are below. =A0

For the WG, we reall= y need feedback from other folks on how to handle this requirement. =A0This= is the only remaining open issue for the requirements document.

Mary.=A0


On Mon, Aug 26, 2013 at 8:07 PM, Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Mary,

I was making a comment to stimulate discussion. If we want to finish the re= quirements document without referring to the other documents e.g. the use c= ases or framework we should avoid using these terms.
[MB] Actually, the requirements absolutely should refer to the use cases. = =A0There are references to many of the use cases referenced in the requirem= ents. [/MB]
=A0
It would mean that we just need to update REQ-14:

=A0 =A0REQMT-14: =A0The solution MUST support mechanisms to make possible f= or
=A0 =A0 =A0 =A0 =A0 =A0 =A0 either or both site switching or segment switch= ing. =A0[Edt:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 This needs rewording. =A0Deferred until layout = discussion is
=A0 =A0 =A0 =A0 =A0 =A0 =A0 resolved.]

I propose rewording to:

REQMT-14: The solution MUST support mechanisms to allow media from one sour= ce endpoint or/and multiple source endpoints to be sent to a remote endpoin= t at a particular point in time. Which media is sent at a point in time may= be based on local policy.
[MB] I'd like to hear from others, but personally, I = think that the requirement stated as is is okay if we add the reference to = section 3.3 to the requirement. =A0 However, I have no issues with your pro= posal either. [/MB]=A0

I think we just need to focus on the "source" and "time"= ; aspect rather than the relation between camera and displays. The display = aspect is up to the local policy of the receiving endpoint.

Regards, Christian


On 27/08/2013 4:42 AM, Mary Barnes wrote:
Christian,

It wasn't clear to me whether you are agreeing or disagreeing with what= I proposed. =A0I was suggesting a very basic definition so that we can com= plete the requirements section. Are you suggesting an alternative to be inc= luded in the requirements document? =A0 =A0I don't think we should have= to wait for completion of the framework to complete the requirements.

One thing I noticed is that the terms (and the text you have) are actually = introduced in the use cases document as follows, so I don't think we ne= ed to re-iterate in other documents. =A0We could easily add a reference to = this specific section (3.3) of the use cases. =A0And, actually, I think the= right thing to do is to just add the reference to the "Multi-point me= eting" use case as a reference to REQMT-13 and REQMT-14.
=A0 =A0 One common policy is called site switching. =A0Let's say the sp= eaker is
=A0 =A0 at site A and everyone else is at a "remote" site. =A0Whe= n the room at
=A0 =A0 site A shown, all the camera images from site A are forwarded to th= e
=A0 =A0 remote sites. =A0Therefore at each receiving remote site, all the =A0 =A0 screens display camera images from site A. =A0This can be used to =A0 =A0 preserve full size image display, and also provide full visual
=A0 =A0 context of the displayed far end, site A. =A0In site switching, the= re
=A0 =A0 is a fixed relation between the cameras in each room and the screen= s
=A0 =A0 in remote rooms. =A0The room or participants being shown is switche= d
=A0 =A0 from time to time based on who is speaking or by manual control, =A0 =A0 e.g., from site A to site B.

=A0 =A0 Segment switching is another policy choice. =A0Still using site A a= s
=A0 =A0 where the speaker is, and "remote" to refer to all the ot= her sites,
=A0 =A0 in segment switching, rather than sending all the images from site = A,
=A0 =A0 only the speaker at site A is shown. =A0The camera images of the =A0 =A0 current speaker and previous speakers (if any) are forwarded to the=
=A0 =A0 other sites in the conference. =A0Therefore the screens in each sit= e
=A0 =A0 are usually displaying images from different remote sites - the
=A0 =A0 current speaker at site A and the previous ones. =A0This strategy c= an
=A0 =A0 be used to preserve full size image display, and also capture the =A0 =A0 non-verbal communication between the speakers. =A0In segment switch= ing,
=A0 =A0 the display depends on the activity in the remote rooms - generally= ,
=A0 =A0 but not necessarily based on audio / speech detection).
Mary

On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves <Christian.Groves@nteczone.com= <mailto:Christian.Groves@nteczone.com>> wrote:

=A0 =A0 Hello Mary,

=A0 =A0 Here's some text I've been working on with regards to the =A0 =A0 framework to better describe site and segment switch.

=A0 =A0 The "site-switch" policy means all captures are switched = at the
=A0 =A0 same time to keep captures from the same endpoint site together. =A0 =A0 Let's say the speaker is at site A and everyone else is at a =A0 =A0 "remote" site.
=A0 =A0 When the room at site A shown, all the camera images from site A =A0 =A0 are forwarded to the remote sites. Therefore at each receiving
=A0 =A0 remote site, all the screens display camera images from site A.
=A0 =A0 This can be used to preserve full size image display, and also
=A0 =A0 provide full visual context of the displayed far end, site A. In =A0 =A0 site switching, there is a fixed relation between the cameras in =A0 =A0 each room and the displays in remote rooms. The room or
=A0 =A0 participants being shown is switched from time to time based on
=A0 =A0 who is speaking or by manual control.

=A0 =A0 The "segment-switch" policy means different captures can = switch at
=A0 =A0 different times, and can be coming from different endpoints. Still<= br> =A0 =A0 using site A as where the speaker is, and "remote" to ref= er to all
=A0 =A0 the other sites, in segment switching, rather than sending all the<= br> =A0 =A0 images from site A, only the image containing the speaker at site =A0 =A0 A is shown. The camera images of the current speaker and previous =A0 =A0 speakers (if any) are forwarded to the other sites in the conferenc= e.
=A0 =A0 Therefore the screens in each site are usually displaying images =A0 =A0 from different remote sites - the current speaker at site A and
=A0 =A0 the previous ones. This strategy can be used to preserve full size<= br> =A0 =A0 image display, and also capture the non-verbal communication
=A0 =A0 between the speakers. In segment switching, the display depends on<= br> =A0 =A0 the activity in the remote rooms - generally, but not necessarily =A0 =A0 based on audio / speech detection.

=A0 =A0 Regards, Christian


=A0 =A0 On 24/07/2013 3:17 AM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 My suggestion is to define the terms "site switching&q= uot; and
=A0 =A0 =A0 =A0 "segment switching" in this document using termin= ology
=A0 =A0 =A0 =A0 consistent with this document. NOte, that these terms don&#= 39;t
=A0 =A0 =A0 =A0 explicitly appear in the terminology section of the framewo= rk,
=A0 =A0 =A0 =A0 however, they are clearly described in 6.2.2. So I think we=
=A0 =A0 =A0 =A0 can borrow some of that text and add a definition to the =A0 =A0 =A0 =A0 requirements document and close this issue. My suggestion i= s
=A0 =A0 =A0 =A0 something like:

=A0 =A0 =A0 =A0 Site-switching:there is a fixed relation between the camera= s
=A0 =A0 =A0 =A0 in each room and the displays in remote rooms. The room or<= br> =A0 =A0 =A0 =A0 participants being shown is switched from time to time base= d
=A0 =A0 =A0 =A0 on who is speaking or by manual control.

=A0 =A0 =A0 =A0 Segment-switching: there is a variable relation between the=
=A0 =A0 =A0 =A0 cameras in each room and the displays in different rooms. =A0 =A0 =A0 =A0 Rather than sending all the images from a room, only the im= age
=A0 =A0 =A0 =A0 with the active speaker is sent from a specific room.
=A0 =A0 =A0 =A0 Therefore the screens in each site are usually displaying =A0 =A0 =A0 =A0 images from different remote sites - the current speaker at=
=A0 =A0 =A0 =A0 site A and the previous ones.

=A0 =A0 =A0 =A0 Please make suggestions if you have alternative wording. I&= #39;d
=A0 =A0 =A0 =A0 like to get this issue closed no later than August 12, 2013= .

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Mary.


=A0 =A0 =A0 =A0 On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker
=A0 =A0 =A0 =A0 <trac+clue@trac.tools.ietf.org
=A0 =A0 =A0 =A0 <mailto:trac%2Bclue@trac.tools.ietf.org>
=A0 =A0 =A0 =A0 <mailto:trac+clue@trac.tools.ietf.org

=A0 =A0 =A0 =A0 <mailto:trac%2Bclue@trac.tools.ietf.org>>&g= t; wrote:

=A0 =A0 =A0 =A0 =A0 =A0 #39: OPEN-3 Conference modes [REQMT-14]

=A0 =A0 =A0 =A0 =A0 =A0 This wording of this requirement
=A0 =A0 =A0 =A0 =A0 =A0 is problematic in part because the conference modes= (site
=A0 =A0 =A0 =A0 =A0 =A0 switching and segment switching) are not defined. I= t at
=A0 =A0 =A0 =A0 =A0 =A0 least needs rewording. This is deferred until broad= er
=A0 =A0 =A0 =A0 =A0 =A0 discussion on layout is concluded.

=A0 =A0 =A0 =A0 =A0 =A0 --
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-------------------------------------+-------------------------------------
=A0 =A0 =A0 =A0 =A0 =A0 Reporter: | Owner: draft-ietf-clue-
=A0 =A0 =A0 =A0 mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com&g= t;
=A0 =A0 =A0 =A0 <mailto:mary.ietf.barnes@gmail.com

=A0 =A0 =A0 =A0 <mailto:mary.ietf.barnes@gmail.com>> |
=A0 =A0 =A0 =A0 =A0 =A0 telepresence-
=A0 =A0 =A0 =A0 =A0 =A0 Type: defect | requirements@tools.ietf.org
=A0 =A0 =A0 =A0 <mailto:requirements@tools.ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 <mailto:requirements@tools.ietf.org

=A0 =A0 =A0 =A0 <mailto:requirements@tools.ietf.org>>

=A0 =A0 =A0 =A0 =A0 =A0 Priority: major | Status: new
=A0 =A0 =A0 =A0 =A0 =A0 Component: telepresence- | Milestone: milestone1 =A0 =A0 =A0 =A0 =A0 =A0 requirements | Version:
=A0 =A0 =A0 =A0 =A0 =A0 Severity: Active WG Document | Keywords:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-------------------------------------+-------------------------------------

=A0 =A0 =A0 =A0 =A0 =A0 Ticket URL:
=A0 =A0 =A0 =A0 <http://trac.tools.ietf.org/wg/clue/trac/tic= ket/39>
=A0 =A0 =A0 =A0 =A0 =A0 clue <http://tools.ietf.org/wg/clue/>




=A0 =A0 =A0 =A0 _______________________________________________
=A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org>

=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue


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




--001a11c2e32895c17304e4edf10b-- From pkyzivat@alum.mit.edu Tue Aug 27 06:53:52 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A421E804D for ; Tue, 27 Aug 2013 06:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, SARE_SUB_OBFU_Q1=0.227] 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 KGPcK+euTqE3 for ; Tue, 27 Aug 2013 06:53:48 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id ADDE521E80B9 for ; Tue, 27 Aug 2013 06:53:47 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Ho2V1m0051ZXKqc5BptnlK; Tue, 27 Aug 2013 13:53:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id Hptm1m01C3ZTu2S3hptnmL; Tue, 27 Aug 2013 13:53:47 +0000 Message-ID: <521CAF6A.60605@alum.mit.edu> Date: Tue, 27 Aug 2013 09:53:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> <51EF2044.3090308@nteczone.com> <521BFBEA.8060804@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377611627; bh=DhoivHsOwXvif2qJ+3VML/Rl6Jt9/62igjyADb3srXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Krqzu26TqVtx0YNnax1PXkodT+p9ke9w25TqieqgKyrbxXmuO2hC8yM75lWSELmml XVwq8Z2bY0aWJ9yVsqr5Pc5Qi0qh10kD67aLXbt8Hsz6FepBW5zjEXWGzgE1p/9DsE 5QrE9nF2MD3c52HjLR/uI1/dbeDHXvbJ7NbmCNX3Km0ybg72Vbo9kCwakJI9hjwSqC f/u3szP+5RX50JgqIav6QEfW8CPKGyyW75HmkW1UU5z4gmXzKD4ZbYla/aIsFGmZXn z2lY11d6lhlG3dmqCJTbNuf/vyVyffWFhVIl/mMMevy5Jp6FBPFeHPmUS+hBJmlVEt WGwpBxUEWRW6A== Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] 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, 27 Aug 2013 13:53:52 -0000 IMO Christian's rewording gets the job done and avoids getting the requirements entangled with terms that are hard to define. Thanks, Paul (as individual) On 8/27/13 9:35 AM, Mary Barnes wrote: > Hi Christian, > > Thanks for the proposal. My comments are below. > > For the WG, we really need feedback from other folks on how to handle > this requirement. This is the only remaining open issue for the > requirements document. > > Mary. > > > On Mon, Aug 26, 2013 at 8:07 PM, Christian Groves > > > wrote: > > Hello Mary, > > I was making a comment to stimulate discussion. If we want to finish > the requirements document without referring to the other documents > e.g. the use cases or framework we should avoid using these terms. > > [MB] Actually, the requirements absolutely should refer to the use > cases. There are references to many of the use cases referenced in the > requirements. [/MB] > > It would mean that we just need to update REQ-14: > > REQMT-14: The solution MUST support mechanisms to make possible for > either or both site switching or segment switching. > [Edt: > This needs rewording. Deferred until layout > discussion is > resolved.] > > I propose rewording to: > > REQMT-14: The solution MUST support mechanisms to allow media from > one source endpoint or/and multiple source endpoints to be sent to a > remote endpoint at a particular point in time. Which media is sent > at a point in time may be based on local policy. > > [MB] I'd like to hear from others, but personally, I think that the > requirement stated as is is okay if we add the reference to section 3.3 > to the requirement. However, I have no issues with your proposal > either. [/MB] > > > I think we just need to focus on the "source" and "time" aspect > rather than the relation between camera and displays. The display > aspect is up to the local policy of the receiving endpoint. > > Regards, Christian > > > On 27/08/2013 4:42 AM, Mary Barnes wrote: > > Christian, > > It wasn't clear to me whether you are agreeing or disagreeing > with what I proposed. I was suggesting a very basic definition > so that we can complete the requirements section. Are you > suggesting an alternative to be included in the requirements > document? I don't think we should have to wait for completion > of the framework to complete the requirements. > > One thing I noticed is that the terms (and the text you have) > are actually introduced in the use cases document as follows, so > I don't think we need to re-iterate in other documents. We > could easily add a reference to this specific section (3.3) of > the use cases. And, actually, I think the right thing to do is > to just add the reference to the "Multi-point meeting" use case > as a reference to REQMT-13 and REQMT-14. > One common policy is called site switching. Let's say the > speaker is > at site A and everyone else is at a "remote" site. When > the room at > site A shown, all the camera images from site A are > forwarded to the > remote sites. Therefore at each receiving remote site, all the > screens display camera images from site A. This can be used to > preserve full size image display, and also provide full visual > context of the displayed far end, site A. In site > switching, there > is a fixed relation between the cameras in each room and > the screens > in remote rooms. The room or participants being shown is > switched > from time to time based on who is speaking or by manual > control, > e.g., from site A to site B. > > Segment switching is another policy choice. Still using > site A as > where the speaker is, and "remote" to refer to all the > other sites, > in segment switching, rather than sending all the images > from site A, > only the speaker at site A is shown. The camera images of the > current speaker and previous speakers (if any) are > forwarded to the > other sites in the conference. Therefore the screens in > each site > are usually displaying images from different remote sites - the > current speaker at site A and the previous ones. This > strategy can > be used to preserve full size image display, and also > capture the > non-verbal communication between the speakers. In segment > switching, > the display depends on the activity in the remote rooms - > generally, > but not necessarily based on audio / speech detection). > Mary > > On Tue, Jul 23, 2013 at 7:31 PM, Christian Groves > > >> wrote: > > Hello Mary, > > Here's some text I've been working on with regards to the > framework to better describe site and segment switch. > > The "site-switch" policy means all captures are switched at the > same time to keep captures from the same endpoint site > together. > Let's say the speaker is at site A and everyone else is at a > "remote" site. > When the room at site A shown, all the camera images from > site A > are forwarded to the remote sites. Therefore at each receiving > remote site, all the screens display camera images from site A. > This can be used to preserve full size image display, and also > provide full visual context of the displayed far end, site > A. In > site switching, there is a fixed relation between the > cameras in > each room and the displays in remote rooms. The room or > participants being shown is switched from time to time based on > who is speaking or by manual control. > > The "segment-switch" policy means different captures can > switch at > different times, and can be coming from different > endpoints. Still > using site A as where the speaker is, and "remote" to refer > to all > the other sites, in segment switching, rather than sending > all the > images from site A, only the image containing the speaker > at site > A is shown. The camera images of the current speaker and > previous > speakers (if any) are forwarded to the other sites in the > conference. > Therefore the screens in each site are usually displaying > images > from different remote sites - the current speaker at site A and > the previous ones. This strategy can be used to preserve > full size > image display, and also capture the non-verbal communication > between the speakers. In segment switching, the display > depends on > the activity in the remote rooms - generally, but not > necessarily > based on audio / speech detection. > > Regards, Christian > > > On 24/07/2013 3:17 AM, Mary Barnes wrote: > > My suggestion is to define the terms "site switching" and > "segment switching" in this document using terminology > consistent with this document. NOte, that these terms don't > explicitly appear in the terminology section of the > framework, > however, they are clearly described in 6.2.2. So I think we > can borrow some of that text and add a definition to the > requirements document and close this issue. My > suggestion is > something like: > > Site-switching:there is a fixed relation between the > cameras > in each room and the displays in remote rooms. The room or > participants being shown is switched from time to time > based > on who is speaking or by manual control. > > Segment-switching: there is a variable relation between the > cameras in each room and the displays in different rooms. > Rather than sending all the images from a room, only > the image > with the active speaker is sent from a specific room. > Therefore the screens in each site are usually displaying > images from different remote sites - the current speaker at > site A and the previous ones. > > Please make suggestions if you have alternative > wording. I'd > like to get this issue closed no later than August 12, > 2013. > > Thanks, > Mary. > > > On Tue, Jul 23, 2013 at 10:02 AM, clue issue tracker > > > > > > >>> wrote: > > #39: OPEN-3 Conference modes [REQMT-14] > > This wording of this requirement > is problematic in part because the conference modes > (site > switching and segment switching) are not defined. It at > least needs rewording. This is deferred until broader > discussion on layout is concluded. > > -- > > ------------------------------__-------+----------------------__--------------- > Reporter: | Owner: draft-ietf-clue- > mary.ietf.barnes@gmail.com > > > > > >> | > telepresence- > Type: defect | requirements@tools.ietf.org > > > > > > >> > > Priority: major | Status: new > Component: telepresence- | Milestone: milestone1 > requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------__-------+----------------------__--------------- > > Ticket URL: > > > clue > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Tue Aug 27 08:53: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 0A34021E8056 for ; Tue, 27 Aug 2013 08:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.054 X-Spam-Level: X-Spam-Status: No, score=-102.054 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, DC_PNG_UNO_LARGO=0.558, 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 tYhTxv9+nBkM for ; Tue, 27 Aug 2013 08:53:07 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9711E81B6 for ; Tue, 27 Aug 2013 08:53:06 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id o13so2492602qaj.2 for ; Tue, 27 Aug 2013 08:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TcsZ7AX3McX+l1YblauO2oaFC43wBJN5oReLFBqEvek=; b=uecn8FEZRKzWkOQyBBb6nwcEePD4o7dkg2n0XFX7GR73mARtBXrPQ/UGEoHapmErU5 P5YuUVcrTnhDlMOdxZkCfO8jeo2orVA2CUkDU8RNc1VYkMak5DK/SS//fiqIUBhyHINV Gu0g5HcmPHFavwAye1Wl+oLbJ5Tuj7sllDfj335fc+pWxZaHuBiLyhOYMw2zIGFHPa/F MznOBUCOJujA5ExrnpqbDeWRZwgEsh1lmuluQXFLPn8ifnxvZ+Cja+2xtVQRSi4fYdLR GK+VOO/ygOdReSifLmA41hJ43a0mc5FL0CGmGFVazirb1Jm+S6grnoDZslU68UXYunHp ldvQ== MIME-Version: 1.0 X-Received: by 10.224.114.11 with SMTP id c11mr23666442qaq.37.1377618785882; Tue, 27 Aug 2013 08:53:05 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 27 Aug 2013 08:53:05 -0700 (PDT) In-Reply-To: References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> Date: Tue, 27 Aug 2013 10:53:05 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/related; boundary=047d7bdc939c5e57c004e4efde9f Subject: [clue] Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:53:09 -0000 X-List-Received-Date: Tue, 27 Aug 2013 15:53:09 -0000 --047d7bdc939c5e57c004e4efde9f Content-Type: multipart/alternative; boundary=047d7bdc939c5e57be04e4efde9e --047d7bdc939c5e57be04e4efde9e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi folks, In reviewing the FW in order to tease out specific security threats that a CLUE solution must address, I came up with a set of comments that I would like the WG to consider. Below is the thread of discussion. Additional feedback (both agreeing with the proposal or not - with details if you don't agree) from the WG is necessary in order for Mark to include these changes. As noted, I will provide some concrete text to go along with a couple of the suggestions. Please send feedback no later than Sept. 3rd CoB. No responses will be interpreted as support for the changes. Of course, there will be an opportunity to provide comments on the updated version of the document as well later, but it's always helpful to get that feedback before incorporating changes. Regards, Mary --as an individual ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, Aug 27, 2013 at 10:18 AM Subject: Re: Comments on CLUE Framework To: "Duckworth, Mark" Cc: Paul Kyzivat Thanks for the response. I have a few responses below [MB]. I will forward the comments to the list to get feedback from the WG. Mary. On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark wrote: > Hi Mary,**** > > ** ** > > Thanks for the good suggestions. In general, all your suggestions make > sense to me.**** > > ** ** > > More comments below.**** > > ** ** > > Mark**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, August 21, 2013 2:23 PM > *To:* Duckworth, Mark > *Cc:* Paul Kyzivat > *Subject:* Comments on CLUE Framework**** > > ** ** > > So, here are the comments I have on the framework based on my re-read to > tease out specifics for the security requirements. One major thing I > noticed is that some of the structural concerns I have are with regards t= o > some of the bigger changes made between the -08 and -09. Again, I looked > at diffs after the various revisions were submitted and thought the conte= nt > was okay at the time. But, as I'm now re-reading from beginning to the e= nd > (for the first time in a long time), there are some areas that I really > stumbled over and I think some more reorganization/editorial work is need= ed > before we could forward this doc for publication. Having been a gen-art > reviewer for a decade, I think similar issues would be raised on the > document by other directorate reviewers (and ADs) if we don't make a few > changes. I wanted to vet these with you prior to posting to the WG > mailing list. **** > > ** ** > > Paul - I'm reviewing this from the perspective that was discussed on WG > chairs mailing list with regards to doing multiple reviews as part of the > PROTO process. **** > > ** ** > > Mary. **** > > ** ** > > Comments:**** > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D**** > > ** ** > > Major:**** > > -------**** > > ** ** > > 1) The abstract needs some beefing up, including setting some context. > Per my comment 3 below, I think it's important to highlight that the > protocol outlined in this document augments and does not replace SIP O/A. > I would suggest to update the text in the Abstract something like the > following. :**** > > OLD:**** > > This document offers a framework for a protocol that enables**** > > devices in a telepresence conference to interoperate by specifying**** > > the relationships between multiple media streams.**** > > ** ** > > NEW: **** > > This document defines a framework for a protocol to enable devices > in a telepresence conference to interoperate. The protocol enables > communication of information about multiple media streams so a sending > system, receiving system or intermediate system can make reasonable > decisions about transmitting, selecting and rendering the media streams. > This protocol is used in addition to SIP signaling for setting up a > telepresence session. **** > > ** ** > > *[Duckworth, Mark] sounds good.***** > > ** ** > > 2) Introduction: I really stumbled over the level of detail that the > document jumps into in the Introduction (which is before any terminology)= . > It goes from a high level description of the problem, highlighting that > this document provides a framework based on the use cases and requirement= s, > directly to the statement: "Conceptually distinguished are Media Provider= s > and Media Consumers". I also think the level of detail does not belong > in the introduction. To me that's more overview/motivation. Previously, > the introduction provided some text as to what is in the remainder of the > document. I think some of the old text needs to be pulled back into this > introduction and the text starting with the "Conceptually" paragraph migh= t > serve very well in a "Motivation" section just prior to the overview (aft= er > the terminology section). I also think the "Conceptually" sentence coul= d > be replaced with text that provides a better introduction to the section, > perhaps linking the term "consumer" to "receiver" and "provider" to > "sender" that are mentioned in the abstract text I suggested above. Mayb= e > something like the following:**** > > OLD:**** > > Conceptually distinguished are Media Providers and Media Consumers.**** > > ** ** > > NEW: **** > > This document introduces the term Media Provider to represent the entity > that is sending the media and Media Consumer to represent the entity that > is receiving the media. **** > > ** ** > > *[Duckworth, Mark] sounds good. But it will take some work to figure out > detailed changes between introduction and overview, and bringing back som= e > old text.* > [MB] Yeah, I know. I can make a pass at that if you would find that helpful. [/MB] > ** > > ** ** > > 3) The fact that SIP and SDP offer/answer are used for basic session setu= p > as well as when needed during the session (as described in detail in > solution documents) isn't highlighted early enough or often enough. Given > we've had lots of folks thinking we were trying to invent something new > entirely, I think it's really important for this be quite explicit early > on. I think this relates to additional text that should be in the > introduction. I think something like the following will be sufficient: = * > *** > > ** ** > > NEW: **** > > This document identifies the protocols necessary to achieve the > functionality per the use cases and requirements. The basic session setu= p > for the use cases is based on SIP [RFC 3261] and SDP offer/answer [RFC > 3264]. The details with regards to this signaling are provided in the > solution documents. In addition to basic SIP & SDP offer/answer, CLUE > specific signaling is required to exchange the information describing the > multiple media streams. The details of this signaling and the informatio= n > required to be exchanged is described in subsequent sections of this > document. **** > > ** ** > > *[Duckworth, Mark] sounds good. We tried to say this about using SDP > O/A, but not until the end of section 4. It does seem better to say it > earlier.* > > ** ** > > Minor:**** > > --------**** > > 1) General: I realize that at some point, someone changed all the terms > to appear as formal names - e..g., capitalized. Personally, I prefer jus= t > having the terms all lower case as I find it easier to read that way. > However, the RFC editor leaves the choice to the document editor, but it > needs to be consistent. So, another pass is needed as I noticed a few th= at > weren't caps that should be and some that were caps that shouldn't be. F= or > example, in the "Conceptually" paragraph I refer to above, "Renderer" is = in > Caps, but it's not defined as a reserved word in the terminology and I'm > assuming that the intent is to only have nouns in all caps? You will fin= d > it awkward if you try to change every occurrence of the reserved words as > sometimes it just won't read right (which is another reason to just use > lower case). **** > > ** ** > > *[Duckworth, Mark] I don=92t care either way. I think it was Stephan who > first suggested capitals, in the old terminology document.* > [MB] Again, either way is okay. But, there are some places where it's not all caps. I also think using lower case is easier just from a basic editing standpoint as it's more natural IMHO to just type the words and not have to CAP. [/MB] > ** > > ** ** > > 2) Introduction: The text in the intro (3rd para) (that I'm suggesting to > move to Motivation section) that starts with "Motivations" reads a little > funky. I suggest to reword something like:**** > > OLD:**** > > Motivations for this document (and, in fact, for the existence of the C= LUE protocol) include:**** > > NEW: **** > > ** ** > > The motivations for the framework outlined in this document include the f= ollowing:**** > > ** ** > > *[Duckworth, Mark] sounds good* > > ** ** > > 3) Introduction: List item (1). I was going to suggest rewording (as it > reads as if the endpoints described are only specific to this document), > but it's not clear to me exactly what that item is trying to say. Can it > be changed to something like the following and still mean what is intende= d? > [As an aside "Media Renderer" isn't a reserved word - I think perhaps i= f > you add a definition for "Renderer" that would help. I actually think > that's probably necessary anyways as I think it's important to distinguis= h > "Media Renderer" from "Media Consumer"]. **** > > ** ** > > OLD:**** > > (1) Endpoints according to this document can, and usually do, have multip= le Media Captures and Media Renderers, that is, for example,multiple camera= s and screens. While previous system designs were able to set up calls tha= t would light up all screens and cameras**** > > (or equivalent), what was missing was a mechanism that can associate the = Media Captures with each other in space and time.**** > > NEW: **** > > ** ** > > (1) Endpoints in telepresence systems typically have multiple Media Captu= res and Media Renderers, e.g., multiple cameras and screens. While previou= s system designs were able to set up calls that would capture media using a= ll cameras and display media on all screens, for example, there is no mecha= nism that can associate these Media Captures with each other in space and t= ime.**** > > ** ** > > *[Duckworth, Mark] Yes, I think that says the intent better.* > > ** ** > > 4) Section 4, last two paragraphs. I'm really wondering how much needs t= o > be said (if anything) about "legacy" in this document. This document is > defining what we need for CLUE. The signaling solution document will of > course get into how this works. But, I think we could just delete the nex= t > to last paragraph and condense the one on RTP to reference the WG RTP > mapping mapping document**** > > ** ** > > *[Duckworth, Mark] okay* > > ** ** > > 5) Somewhat General. There was a diagram in Section 5 in the -02 version > that was dropped in the -03. I really think that more diagrams would hel= p > to understand this stuff. **** > > ** ** > > *[Duckworth, Mark] That was the precursor to this. The -02 diagram > doesn=92t really say much, but I could try to update it. The one below i= s a > bit much to convert to ASCII.* > [MB] I can convert that to ascii art. I did all the diagrams in RFC 5239. This is just a tad more complicated than some of those. [/MB] > ** > > * * > > **** > > ** ** > > 6) Per my other email, I believe these should all be normative references > and RFC 3264 needs to be added. **** > > ** ** > > ** ** > > Nits:**** > > -----**** > > 1) Section 4, next to the last paragraph - starting with "Legacy > devices": **** > > "here in" -> "herein"**** > > ** ** > > 2) Section 6.1.1. I think it would be really helpful to indent the text > that goes along with the attribute name. Several of the descriptions go > beyond one paragraph and it would be much more readable if the attribute > name was easier to pick out. **** > > ** ** > > 3) Section 6.1.1. Language attribute. Add a space between "multilingual= " > and "and/or accessible". **** > > ** ** > > 4) Section 6.2.2. 4th paragraph (beginnning with "When the room at site A > shown") add "is" between "A" and "shown"**** > > ** ** > > 5) Section 11.2. 1st paragraph. It would help to add an explicit section > reference since I believe the previous section being reference is 11.1.1 = is > several pages back. **** > > ** ** > H --047d7bdc939c5e57be04e4efde9e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi folks,

In reviewing the FW in order = to tease out specific security threats that a CLUE solution must address, I= came up with a set of comments that I would like the WG to consider. =A0Be= low is the thread of discussion. Additional feedback (both agreeing with th= e proposal or not - with details if you don't agree) from the WG is nec= essary in order for Mark to include these changes. =A0As noted, I will prov= ide some concrete text to go along with a couple of the suggestions. =A0 Pl= ease send feedback no later than Sept. 3rd CoB. =A0No responses will be int= erpreted as support for the changes.=A0

Of course, there will be an opportunity to provide comm= ents on the updated version of the document as well later, but it's alw= ays helpful to get that feedback before incorporating changes.

Regards,
Mary
--as an individual

=
---------- Forwarded message ----------
From:= Mary Barnes <mary.ietf.barnes@gmail.com><= /span>
Date: Tue, Aug 27, 2013 at 10:18 AM
Subject: Re: Comments on CLUE Framew= ork
To: "Duckworth, Mark" <Mark.Duckworth@polycom.com>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>


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

Mary.=A0

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

Hi Mary,

=A0

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

=A0<= /p>

More comments below.

=A0<= /p>

Mark

=A0<= /p>

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, August 21, 2013 2:23 PM
To: Duckworth, Ma= rk
Cc: Paul Kyzivat
Subject: Comments on CLUE Framework=

=A0

So, here are the comments I have on the f= ramework based on my re-read to tease out specifics for the security requir= ements. =A0One major thing I noticed is that some of the structural concern= s I have are with regards to some of the bigger changes made between the -0= 8 and -09. =A0Again, I looked at diffs after the various revisions were sub= mitted and thought the content was okay at the time. =A0But, as I'm now= re-reading from beginning to the end (for the first time in a long time), = there are some areas that I really stumbled over and I think some more reor= ganization/editorial work is needed before we could forward this doc for pu= blication. =A0Having been a gen-art reviewer for a decade, I think similar = issues would be raised on the document by other directorate reviewers (and = ADs) if we don't make a few changes. =A0 I wanted to vet these with you= prior to posting to the WG mailing list.=A0

=A0

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

=A0

Mary.=A0

=A0

Comments:=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= u>

=A0

Major:

-------

=A0

1) The abstract needs some beefing up, including setting som= e context. =A0Per my comment 3 below, I think it's important to highlig= ht that the protocol outlined in this document augments and does not replac= e SIP O/A. =A0 =A0I would suggest to update the text in the Abstract someth= ing like the following. :

OLD:

=A0=A0=A0 This docum=
ent offers a framework for a protocol that enables

=A0=A0 devices in a telepresence conference to interoperate by s=
pecifying
=A0=A0 the relationships bet=
ween multiple media streams.

=A0

NEW:=A0

=A0 =A0 =A0 =A0This document defines a fra= mework for a protocol to enable devices in a telepresence conference to int= eroperate. The protocol enables communication of information about multiple= media streams so a sending system, receiving system or intermediate system= can make reasonable decisions about transmitting, selecting and rendering = the media streams. This protocol is used in addition to SIP signaling for s= etting up a telepresence session.

=A0

[Duckworth, Mark] sounds good.

=A0

2) Introduction: =A0I really stumbled over the leve= l of detail that the document jumps into in the Introduction (which is befo= re any terminology). =A0It goes from a high level description of the proble= m, highlighting that this document provides a framework based on the use ca= ses and requirements, directly to the statement: "Conceptually disting= uished are Media Providers and Media Consumers". =A0 =A0I also think t= he level of detail does not belong in the introduction. =A0To me that's= more overview/motivation. =A0Previously, the introduction provided some te= xt as to what is in the remainder of the document. I think some of the old = text needs to be pulled back into this introduction and the text starting w= ith the "Conceptually" paragraph might serve very well in a "= ;Motivation" section just prior to the overview (after the terminology= section). =A0 I also think the "Conceptually" sentence could be = replaced with text that provides a better introduction to the section, perh= aps linking the term "consumer" to "receiver" and "= ;provider" to "sender" that are mentioned in the abstract te= xt I suggested above. =A0Maybe something like the following:<= /p>

OLD:=

Conceptually distinguished are Media Provid= ers and Media Consumers.

=A0

NEW:=A0

<= span style=3D"font-size:13.5pt;font-family:"Courier New"">This do= cument introduces the term Media Provider to represent the entity that is s= ending the media and Media Consumer to represent the entity that is receivi= ng the media.

=A0

[Duckworth, Mark] sounds good.=A0 But it will take some work to figure = out detailed changes between introduction and overview, and bringing back s= ome old text.

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

=A0<= /p>

3) The fact that SIP and SDP offe= r/answer are used for basic session setup as well as when needed during the= session (as described in detail in solution documents) isn't highlight= ed early enough or often enough. Given we've had lots of folks thinking= we were trying to invent something new entirely, I think it's really i= mportant for this be quite explicit early on. =A0I think this relates to ad= ditional text that should be in the introduction. =A0I think something like= the following will be sufficient: =A0

=A0

NEW:=A0

T= his document identifies the protocols necessary to achieve the functionalit= y per the use cases and requirements. =A0The basic session setup for the us= e cases is based on SIP [RFC 3261] and SDP offer/answer [RFC 3264]. The det= ails with regards to this signaling are provided in the solution documents.= In addition to basic SIP & SDP offer/answer, CLUE specific signaling i= s required to exchange the information describing the multiple media stream= s. =A0The details of this signaling and the information required to be exch= anged is described in subsequent sections of this document. =A0

=A0

[Duckworth, Mark] sounds good.=A0 We tried to say this about using SDP = O/A, but not until the end of section 4.=A0 It does seem better to say it e= arlier.

=A0<= /p>

Minor:

--------

1) General: =A0I realize that at some point, someone changed= all the terms to appear as formal names - e..g., capitalized. =A0Personall= y, I prefer just having the terms all lower case as I find it easier to rea= d that way. =A0However, the RFC editor leaves the choice to the document ed= itor, but it needs to be consistent. =A0So, another pass is needed as I not= iced a few that weren't caps that should be and some that were caps tha= t shouldn't be. =A0For example, in the "Conceptually" paragra= ph I refer to above, "Renderer" is in Caps, but it's not defi= ned as a reserved word in the terminology and I'm assuming that the int= ent is to only have nouns in all caps? =A0You will find it awkward if you t= ry to change every occurrence of the reserved words as sometimes it just wo= n't read right (which is another reason to just use lower case).=A0<= /u>

=A0

[Duckworth, Mark] I don=92t care either way.=A0 I think it was Stephan = who first suggested capitals, in the old terminology document.

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

<= u>=A0

2) Introduction: The text in the int= ro (3rd para) (that I'm suggesting to move to Motivation section) that = starts with "Motivations" reads a little funky. =A0I suggest to r= eword something like:

OLD:

=A0 Motivations for this =
document (and, in fact, for the existence of=A0the CLUE protocol) include:


NEW:=A0
=A0
The motivations for the fram=
ework outlined in this document include the following:=

=A0

[Duckworth, Mark] s= ounds good

=A0

3) =A0Introduction: List item (1). = =A0I was going to suggest rewording (as it reads as if the endpoints descri= bed are only specific to this document), but it's not clear to me exact= ly what that item is trying to say. =A0Can it be changed to something like = the following and still mean what is intended? =A0 [As an aside "Media= Renderer" isn't a reserved word - I think perhaps if you add a de= finition for "Renderer" that would help. I actually think that= 9;s probably necessary anyways as I think it's important to distinguish= "Media Renderer" from "Media Consumer"].=A0<= /u>

=A0

OLD:

(1) Endpoints according to this documen=
t can, and usually do, have multiple Media Captures and Media Renderers, th=
at is, for example,multiple cameras and screens.=A0 While previous system d=
esigns were able to set up calls that would light up all screens and camera=
s
(or equivalent), what was missing was a mechanism that can assoc=
iate the Media Captures with each other in space and time.

NEW:=A0

=A0
(1) Endpoints in telepresence systems typically=
 have multiple Media Captures and Media Renderers, e.g., multiple cameras a=
nd screens.=A0 While previous system designs were able to set up calls that=
 would capture media using all cameras and display media on all screens, fo=
r example, there is no mechanism that can associate these Media Captures wi=
th each other in space and time.
=A0
[Duckworth, Mark] Yes, I think that says = the intent better. 
=A0

4) Section 4, last two paragraphs. =A0I'm rea= lly wondering how much needs to be said (if anything) about "legacy&qu= ot; in this document. =A0This document is defining what we need for CLUE. = =A0The signaling solution document will of course get into how this works. = But, I think we could just delete the next to last paragraph and condense t= he one on RTP to reference the WG RTP mapping mapping document

=A0

[Duckworth, Mark] okay

=A0<= /p>

5) Somewhat General. =A0There was= a diagram in Section 5 in the -02 version that was dropped in the -03. =A0= I really think that more diagrams would help to understand this stuff. =A0= =A0

=A0

[Duckworth, Mark] That was the precursor to this.=A0 The -02 diagram do= esn=92t really say much, but I could try to update it.=A0 The one below is = a bit much to convert to ASCII.

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

=A0

=A0<= /p>

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

=A0

=A0

Nits:=

-----

=

1) =A0Section 4, next to the last paragraph - starti= ng with "Legacy devices":=A0

=A0 =A0"here in" -> "herein"

=A0

2) Section 6.1.1. =A0I think it would be really helpful to i= ndent the text that goes along with the attribute name. =A0Several of the d= escriptions go beyond one paragraph and it would be much more readable if t= he attribute name was easier to pick out.=A0

=A0

3) Section 6.1.1. =A0Language attribute. =A0Add a space betw= een "multilingual" and "and/or accessible".=A0

=A0

4) Section 6.2.2. 4th paragraph (beginnning with "When = the room at site A shown") add "is" between "A" an= d "shown"

=A0

5) Section 11.2. 1st paragraph. =A0It would help to add an e= xplicit section reference since I believe the previous section being refere= nce is 11.1.1 is several pages back. =A0

=A0


H
--047d7bdc939c5e57be04e4efde9e-- --047d7bdc939c5e57c004e4efde9f Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: 5ea8dcc11eb439d3_0.1 iVBORw0KGgoAAAANSUhEUgAAA0QAAAHnCAYAAACYDp1HAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAMbASURBVHja 7b0JfBX1uf/P/7ZqbW2lrb/aVmtp6y3WohcQBbxeSy2l1lJbihQBEYoSl7pjixURFBfEhUVB9h3C HraEJYQsEEjY9yVhF8K+iRosTZ7/85ycSb4zZ9Zz5pyc5dPX6111lu82Z2aed77L1HnttdfqAAAA AAAAAEAqgkYAAAAAAAAAQIgAAAAAAAAAAEIEAAAAAAAAABAiYEbPnj3rdu3atYWQlpbW0O2xTvCx 37dL65lnnrnJbVpOdXCbjuTpUL/v+1U/acsEr19dP+rHxzWzS6d///5fc1umHj161LNLS/a7TUvy dahfM5f1S+p7xkX9vp/I9cM9g3sG9wzumWS6Z5zyBBCilEVujnr16uUKV1xxxdk6deqQFXKM0wPT 7nyVNm3adLVLq2HDhuPcpuV40V2mI3napSNl9qt+0paJXD+nF6jb+tWtW3e/08vFbZlatGjR1y4t 2e82LaeXnpTbTTrJfs841c/PeybRnwm4Z3DP4J7BPROP94zkI2nceOONi9q3b/9nxMYQoqTE6YYT rrrqqqN4UUGI8KJCcIfgDvcM7hncM7hnUveeadmy5UuQBQhRUiDd0e3atXtQHkrazeTUnSp/Fbjm mmt2aj1FGg0aNEiXm1vD6eErN7d6vB1OZZK/UrhNy6lN3Kbj9JcRKbNf9ZO2TOT6OT3I3davVatW zzn8nuu6LZPTy1P2u03LaaiGlNtNOsl+zzjVz897JtGfCbhncM/gnsE9Ew/3jMSHxnjv2muv3Sjx osSPTr8DiRebNGnysRzrNGwTQIhiityA8uOUH6mZ8Ts9DAAAAAAAALBDEycVTZCc5moBCFFUECsX U7frUpV98pcANxMmAQAAAAAAsEJGDtlNs5C4U2JTp8U1AITIN8zGvMqiCPXr189o3br14/gxAgAA AAAAv5EYU2JNK0FymtcEIES+oq0MJ71AWBkEAGAHv7y6t2rVqge/yG5Ae6BdAADAL2S4nAyb01Yr dprXBCBEviK9RFhTHqQ6PXv2/J4Es0ZkexK9bP5HgnanCa9WSHtof7nr3LnzPYlW/2hd00Rvl1j/ jgAAwAl5viA2hRD59dJqKEPfsBgCAM4y5LSMqPQAJPpf//l5MF+rTzh1SeTAX16u6vXka341hKh2 fkcAAOAHTZs2HYhFGCBEdiLUTF1XX8ZlwrIBcBfQOiF/HU/UespQBEUIvhdJOyVa4K8G8X6XP1mE SKRRen6efPLJn0fzdwSif40ASHZkioc618hp+XiQQkIka9GLLZtNSnPzYVUAIEShAa0EfLJNvacS 9a/i0isSyZCxRA38RWK1cmvBvPwTQmR4sbmsQ6S/IxD9awRAsiMLMRjjXYmBnb7LBJJciOSvRsYV Oq6//vrVWCobAH8CWul5VYfPoZ0SJyCT6xX8llqPDh06/NHv3o1UEyKAawRAPCC9RMZvGkksjPmN KShEsmThjTfeuMj4Y8DKHAD4H9CqQ4W8pO32OD/ntfjVLpEG/lpvgp/lCDeIlJ4iKY/23yJHtdUu 4RLN9ozWcMJwftd+1NPtbyeSfGJZTggRAOZIzGvsFJDRUfh0TIoIkcwL0pYmRHchANEXIulhsBIi rQdJ+8uUBN/qvBXjxE8JpORY49wWrQfKrPdCG/ol5zgFUNoiAnfffXc/YxnthovJ3AQ5Ry2P1Ftb hc9NO2l1M9ZL0rWbg+W1Dd2g9uxp27T6Sdpu0wmnXSK9XrFoT6mX1EP9bcvvQ9smGK+10+/IrK0k X6e/2vpVT2lrtT7KPXW1mpfWc2i8nm4kyI9ySl7Gckoaxt9KONcIgFTDbNrIV7/61XIsLJYCQiS0 bNnyJW14HCaUAVB7QqTNM5Jj1DkrVoGymQg5LeCgrobnFFyaDe9T50KZnaMOJzNDDQJthhbq6ib/ rvas2ZXdSxu6RQvM1XZQJcnN5PRw2yXS6xWL9jTOjzNDzjdL1+4+UAN8tfy18btR09QEw+r+k+12 UhSLchp/l+FcIwBSFXm+S0ysCRFWoUsRIZJeInxMFYDYCJEWCJn1LGhBizH4k7TlgazJjQRbajpG 6ZFj7ZY11oIvu94NNdiyCqzs2kDS1s6Tv4abBWRm7aQKgNlfulVxMHtJuW1DD38xvNpMLtXtTqIS abtEcr1i1Z7a95nUNjF8i+tqN0Jk165SF9lmVk6/6xm8r5ppaau9Veq/y3lSZmOPj9UcwWiUUy2D 2q7G3jev1wiAVIfv48cFtEWKCBEAIDZCpAYrZkG0MTi2Ct7VXiarv0Sr5TH+5ddN74Y2FMgYhNsJ kRoo2g3Xs2snrW52wb92jNlwK7dt6Ba39bVLI9J2ieR6xbo93fbEWbWr1C+c7zz5WU+rHh5jj5BZ WzjNEYxFOVWpMhtmiTlEAAAIEQAg5kJk/MttMJC52i7YsZqs76VnwiBOV3tJw2p/OH/ZtwruzdrJ TbCmCoQxIHTThl7QAlyzv/ir5bASBb/bxcv1qo32jFSI7Mpihd/1tMrX0HvzP071MspIrMqpPovM epkgRACAlBQieSBiQhgAsRMiO+zmFzjNzzEGS05zV9T0jMfaLQqg5mEM6tz8Zd+uF8FOHO3ytUrD bfnCQR3eZFUnp/kXfrRLuNerNtozUiFSpcFsSJnTPRHNero5Rr3exjxieT3srgOECAD/wDc6E0SI +IF3r0wIk4cfltEGoPaESFshy24YkNegzClYdCsfRlnShl85DdkJp1x2ZVLTkGBYXQFLxTiHI1pC pPUI2A1vUlcZc+r1C7ddwr1etdGekQqRYFyAQltAwE1a0aynm2Pcyky0rweECIDoc9ddd70tKzVL rI32iGMhEgFSXyoNGzYch4YHIPpCZDJZ2dXQH7+CMrdBttUEcLshUrESIrdEs4dImzMioqGtpmZE HZZoNwk+UiEK53rVRnv6IUSaABpXXpP/NusVjVU9/RSiaF8PCBEA0UUdQisdD+h0iFMh0pbS1hCL RaMDEBshCjfQ8BqUOYmWU5nU3g01EHXb4xFNIQr3Q5V+CZE69MktZt//8VOIvF6v2mhPv4RIrZ/x Ozu19bvxU4iifT0gRABEH+MfbTA9Jc6EyPhRKSwZCEByCpFTUKVO1Dc71mxRAC3oNgvu7cro9rs8 DsP4msWLEKnyYTW0SUN9KRol1Y92Cfd61UZ7+i1EavtYLVkfq3pGKkSxvB4QIgBig7EDQmJwtEsc CJH6YpYuPKdVqAAAiSVEaj5Oq36Z9SgY0YJMbRiW3fAvuzK6LZca1BvbyUvdoi1ETt+TsaqTsdx+ tEu416s22jNaQmRsI1UoYlXPSIUoltcDQgRA7JDhctp8fUxRiQMhatGiRV/tYsgkr65du7ZAQwOQ XEKkBsVWy3cby2P3hxHjhyCdvgFjV0a7j84K6gdlrdrJzUdIoy1EbpbTtqq72UIUfrRLuNcr1u3p tOqeX0Jk7ImLRT0jFaJYXg83QuR0jQAAnu7NeyX21u4vicnRLrUgRHIh1J4hfnE0RCMDkJxCZFyt ymx5XzfSZCy3sffBaxmN5VLzleBdLZPNamrNnJZdlmBY/sLuZdEHL7j5eKadqBiHxvnRLuFer1i3 p9lHaKW+dvObjG0vmH3DR0vbTDpjUU8/hChW18PNEu5O1wgA4PmPaQ3VniLMKaoFIerfv//XpIsu +ADE8n8AJLEQGQNwu6W+nb5VJBgnhrpd4tgpIDZDnSRv1U7Gukk9tEDZuByz30Lk5cO3KuoiDGbn +dEu4VyvWLenGvDbpW2VrjrMU+ppXIbabi5WtOvphxDF6no4LOHu6hoBAMJ6j9+rPsPQJjEWItVO 0bgA1K4QuR1mZRXsuO2ZMFuaWA3K3f7FVw2ynPJ2U0YzWZNgS/trtBb4Wc1Tcqqb8k2n70Xahmb5 hjvx3WlonB/t4vV61UZ7Gr8jZLcynDFd+c1ayb6bD7VGs56qSEQiRLG4Hk5/nHFzjQAA4SFzijBk rpaFCACQekgQqX73KJ4kMfgdpqv9qlsyDOupzbrEsj0jzSOScibK76a2y5lM9xUAAEIEAAAAAAAA ABAiAAAAAAAAAIAQAQAAAAAAAECyCZFM6rz22ms3YvEEAAAAAAAAEgeJ35955pmb0BYRCFHPnj3r 8v/241tDAAAAAAAAJA6tW7d+XOL3a665Zqd8LgdtEqYQ1a9fP0NZljMj6RqkTp3/DwCQmOChDgAA ALiL4+XboWiTMIRI/S7DVVdddVR6i5JJhB4fOv7lVjMKCQCQWPx+RuGlHv3fu3PGjBn/BTECAAAA zFFHegnt27f/M9rFgxBJt5pIkNaAXbt2bZFMMiSB1N/Gzp0zrfQ4Hf6SAAAJRO+C7RfS3vv4sWee eeYySBEAAABgjfqBZ4ntMXTOgxA1bdp0oNZ48mXrpGoEDp4GDx58+cNj5swTIfqEAywAQOIgQtSt /4fP9uzZ85tyL4sU4aUHAAAAmCOxvBbXS4wPIXJnkg1lApYyVO77ydQI7dq1+wrb8dcfGjl7IYQI gMQUoi5vvPcSP5u+x1wp9zR6iQAAAABzZOicNvILi6S5FKJ69erlahbZpk2brsnWCIMHD/6q/GW5 08iZWRAiABJTiDr1HdDnmWeeub5///5XyT0NIQIAAACsUdcGkFgfQpTijRUUoqs7jpyxGEIEQGIK 0YOvvv0638c/Zr4FIQIAAACcSfZOD9+ESIbHybJ80p2WrB9xqhai4TMWp7MQHeIACwCQOIgQtX/1 7Tf4GfUTCBEAAADgDonttWkxqbwMt+sDk23ekK0QXSQAQAIBIQIAAADCo1WrVs917tz53lRuA/wQ IEQAQIgAAAAAACGCEFUJ0VQWooMcYAEAEodXIEQAAAAAgBBBiACAEEGIAAAAAAAhghABACFKeSGS +gOQ6CBGAQBAiCBEAAAIkWcRGvHGM3ce+Kjd+oND/7oRgESlZPBfV/Tt2/c7ECMAQMyFSNYgl9Um +vfv/7VUFaIDHGABABIHCFGNDM2YMeO/ZryV9shn6Y9/UbFtAQGQqHw67A9f9O/T4xfo8QUAxFyI rr/++tWyFnndunX3p4oU+SNEpfRqs6oPW+lJo3EIWD0x7hGTdnwkK/nrvn0QNXbz25mXVn1Mx3n4 vUCI9ELEbXDZ1Ne7Pf757Bcv0LGdBECicn74ny680atHY76nvwEpAiB2tGvX7sEbb7xxkThBSgqR fJxJC7Tq16+fgR4id+S/d6eJCKncSa9ur6XAutkgyk+YwDaLOtq0Y+P3SpM7sFdEx7bOECIIkYUM 8UvsK1z/K6f27fp0QIiO8oMHgARFhKhPjyd/xb/p7/A9fTmECIDYIA6gxRk9evSol3JC1KJFi75a A4gdpqIQTWEh2s8BllvyDDLUYZ7hmEDwWiVEXtKNCIMQ5V2MYd4RoPYMiQjU7KvqfdNvS0JMhEjr JbI6LuT3lqL0ghCpQvSNiX26PB8QorKtBECiIkLU65lHfycfhhfRl983glUAYtNDpMUZ4gYpJ0Qy TE4qf8UVV5xN1TlEnoTIMMQpboLThBSiLOpg6FFLucBeFZ1H0izkEEIEIbIWIqk3P7uvmti7c4/P Z/W4QEc2EwCJyvnh91/o9VS3P/A9/UP+XX8dQgRAbBAH+OpXv1ouccY111yzM6WEKC0trZkWZDVp 0uTjVLrw4QqRrnfokawwg/86tmnU5BHsKQjpRdD3IJjOvzEE1mq5zXu0TALx6u1VsqLmY5dGHddi FqYQWQwzc9X7YlImx/a2q0dY9bZq+0FKexh6iSBEECIbIeL6f7NKiF64QIc3EgCJighRzye7/pF/ 09dBiACILQ0bNhynxRriCCkjRE2bNh2oVbxr164tIERO6BdRcDucK89xvpE++FUD9A6P2M9RipUQ NTYsHqGmYZe/6fAvi/Z0DvatFrGIrEw1bRNaT7t6hF9v67ZXr5P5tYAQQYjshOj5C/TJOgIgUYEQ AVB7dO7c+V4t1rjrrrveThkhuuqqq45qq8ul2kVXhWgyC9E+DrCc0ffySGDq5rzcQJB7J/Xert8+ 9hHztHKNAvVIVnBfKfVuZradMQyZyzUtg0W5DUG52XYz+TCma3muWs6L1nmb19miXXR1rLou4ZbJ 2N415+jb2+oahVVvy7bP0vUSjTU5zu3vLtmBEFkI0aE1BECiAiECoHbR3ED+mRJCJD1CqWSBtkJU wkJUTi4wCNFccnmeObnvKkH1u6Wm2wOBv3reNnUOEwfMZtuN5xjSDCn33DTTcqjbQ/YFUIVBKYvj Puv8jb1gvbeZpadup4jLZHUdrPf5VG+rtnfYFunvLlnolQ8hChGimc9doINFBECiAiECoHaRKTSp Mmwu8H/q6nKpNlyudoTIYg6RgxCFSoh+3k21GERbiKS3w2Od6tTxIAaWYqSda+g5CbOdzcpk296m beBjvU3b3kSqIEQQIldC9OwFOrCKAEhUIEQA1C5qh0myrzYX+L/WrVs/LqtIyIoSqbS6nJUQ7eUA yxn9ECoJYN2ct/zdOx2DZzWt5YYA3boMVUIU2G4QouU2ZZCAWpemISg32y4yEFK3bcaPilqLwRhX 7WuSr1Zeh/pFUibb9jZrAz/r7aLtA9sNQrS3HECITIRoBgvRvpUEQKJy/uM/QogAqEXU1ebq1auX m/RCpMEPnbqpeMHDEyKiMY/UsZeEEEJ7dJzEx16ILNKrbSGyk5QwUNs5RIjsRCOMMkUkRJHW26rt Db1EYyBEECJXQvTMBdpbQAAkKhAiAGofWXStZcuWL6XEkLlUJ1wh0vde6AXHMUA3SIUbIQoRESsx 8CBExqBflQ9PQmQje5FhWMxgrpe8vJfJsxD5WW9LIdJf08bN7oQQQYhcCNHTF2hPHvlN6Su/rP79 3fnKFIpGHslYNuAdCBEAAEKUCEJk7CUyC4gDQa62XT/3ZYzF0C5LIdIF4nZD9izyMRW5mv1jHrEe uucsRIbzQ0SsqkyWQwuDbWDXY6WmaZ1XVbto6Xgtk3chirDeboXI5PpAiCBEtkI0/akLVLqcvJD1 oMlwzwfftj7GsK+2Ke2lCFGvSXFVNuAdCBEAAEJUS0I0iYVoDwdY7imlV5o5zR+5k17ZVnX8mEfq uJpDpKWf42LOkSY1arnM8qlJ16bMze6s6YlQyrHHIAPmbZFFD3qomw7HuTg1begmrwfnhlemHIMQ 6cpo2QYR1NsifdPjTdqopp6pDYTIQohKlpE73qI0m9/vnb0mVB+rl44J5D6P6GNZtuwn6U6tPo2e pNI4KjOwBkIEAIAQJYwQOQX0obISKjlyTE1QbRugG1dfs5STUOnRB89W+83L4U6I7CTOKDQe2tAm P3vx816m8IQownq7FaKQPDykDSFKQSH6+wXavYTckNVekZ+Xxyr7xtKgRsZt8Uvpyzeb12Pp44oQ PU6lCVAXsARCBACAECWcEEUJ2wAdAAAhshKiaU9eoJ2LyJnXld6hm2nQEjfnxCel/1KE6F9javYt eUwRoseoNEHrl2qc/7g1hAgAkDpC1Kdv3x/06D/418Lzb31wT6x5pv97v33yjQF/bDcmY8276/bS wkNn4oYxQx6i7/yyUYA7hmyNq7IBsPjwOSr5ojJAKYtJbfEyhChUiNKfuEA7MsmZ1xQhuokGLbY/ vvRfNynSMdpk+72UJdtG3GvoLQ1uN9vXKI1KbfJJG2Eoh3K+eRlqtmf91WYooHKuvh0U/vqaTRtY 1NWkPmRVd6fjF6fVyJxl2cNvM8s8TOodayBEAICYvUPlG0Ty4aXa+v6QvMQ7TV68qsuC4guPLV53 ttbIWnuu++IN/34yZws9s3xb3PDU4iLqmrEywCOL46tsAPw5o5gWsRjt/ryiVqUIQmQhRNsXkDMj aVBDfTCcNtz6+NKXFOl4aaTJ9pvozoZWEnIvpbWz2NewO5Va5BNSnuH3OpShZntWOxshCh6jnmdV 7izTstnXNcvQdnZl8X68/20WQru+5O43FB0gRACAGL5Dqx58tSFE2gu8Y3r25pyyc3T4SwIAJBAi RXNKymj7uYu1KkUQIjMhevwCbZtHrvj4dxYBcZ+QY0t7KtLRc7jpdv25fUJ7Xiz2pX1sno+63Vhe qzKo2ynr0ZoekIaPUqlpnW6iQVn67aqQWJVNn9dwnVxanaMrm9r2anvrrsnvKKu6XPo8rOrvrs2U 9je0S6DuJtc/lkCIAIgfGjZsOE4+ztqgQYP0pBWia665ZmdtZC4PN37QXdlhytJty1iIPuEACwCQ ODzNQjRl817acPw87fj037Rbhs+xoMQaCJGFEG3NINcMa2XRU1CfBmXWHFfas74SWA8z3V6nXW9d 2m73WaWXNsy6rFbnqNsps5siRN2o1GWbuCmbLh/LfcMUiWlFWbp8zPap2/TtH1IfJT3vbdZbESL3 7RIrIEQAxA/iCrXpDDERovr162fU4sv7Ww9OXrIDQgRAYgrR6NVbqPjwSdp6tpx2fV5RK1IEITIR oqmPXaAts8kzw35rIkW/pazg/tJ/KgH/Pz+qPs9quzFNt/vU9NKGzfZ8ji6fhX9ThOhvVGpa91fs lx4Po651HnjFVdqh7aweX9P25mVlYVoYfptlPWAiwAvD+N1EgfPDIEQAxAviCtpzImmF6K677nq7 ll7el/fp0+fb7Scv3gkhAiAxhejj/HVUuK+MNp/6nHZe+A/t/lwWWaCYAiEyE6K0C7RpJoXNR3ox SvuoanvpP35eE1j/48Pq4622G9Nyu09NT8vbyzm6fBZ0rRGiW7tSqaGu6nmWQhRGXes88HJo/k5C 5KK8tOlDGnSrds7PadCC8NtMn5ZKTbq1xflhf4AQARAniCtozwd+196UlELED5kHa+PlzQ16BQvR d0WIslmIDnGABQBIHESIPspdQyv2HIYQxZsQTel+gTZOo0jIaqsKUdU2vQwMrj7WanuAj1p63qcP 7qd5PkeXz/wuimB0oVJdPV9SeltYAuZPc0zPbV3rtH3JRf5mqGVqSVku94fTZiqhYmiWd+yAEAEQ P7Rp06ar9mxo3779n5NSiGSVOQgRACAsIVpeTAUsRJtYiHawEO1iIdrNkhJLIERmQvToBdowhcLn A13PQdqQqu2lL/53TWD94gfVx1ttDzDkHs/77NJTRc3VOfM6K0LSmUrV/NV9bf+pyyfSutak909F YP6bBs3z0vYmx1vUJ5w2M6PmWDdljR4QIgDiB3EF7RkicgQhipYQHWEhukgAgAQCQhTHQjSZhWjd JHIk46FAcJ022LB9sBLY3/oQlQa3l/ZQgu4e71Ufb7XdmJbrfWr+de6hrOD2rL8YhrK5KsOLipDU pGW7L9gukdS1zl9erN6uK7fSnmoZrPLQH/+eTlQjajPTa/+eXsYyXPyGogSECAAIUUyFKC0trSGE CAAAIUomIXrkAq0dT45kdHSY33IjB8U1x5e+cGNNYP3CAMftAQb/Oox9A2jQLRZluuXG6jK7LYNR CtRjzPZZHeulrnX+8oKy7wXHhRVc1980/TDazOHah9QtxkCIAIgfZN6Q9mxo0aJF36QUoh49etSL ByE6yAEWACBxECH6kIUoPyhE21mIdrIQ7WJJiSX/ghCZCFG3C7RmDLlizoPmgXGb50KO1cvAW47b Awy+O7x9a94KCfDTBsv256rlwnUZLNMKPbeKuykrnHyU+ji1n04651hcGzU9N8d7bDPza2+XfuyA EAEQP4grQIggRAAACFFiCdGkv12gopEEQKICIQIgfuD78PuaEDVt2nRg0r1DZUwgP2i+BiECAECI kkmIulyg1R8TAIkKhAiA+KJevXq5QsuWLV9Kundobb68VSFaykJ0gAMsAEDiACGKYyGayEJU+BEB kKicHwohAgBAiAAACSBEQ1iI8liINrIQbWMh2sFCtJMlJZZAiEyEaMLDF2jFYAIgUTk/9PcQIgAA hAiAsJiXpkwOTqNxaBMIUUoKUecLVPABAZCoQIgAABAiADyTRR1DVkuCEEGIUlWIHrpA+e8SAIkK hAgAkHJCtISFaD8HWF4Z90joUrGN3ysNK62kZvsgamyUhUeykqd+ul6hUCHCbyA6PMVCNJiFKJeF aAML0VYWou0sRDtYUmLJSxCiUCEa3+kC5fYnABIVCBEAAEIUdgAcAymqzvtOenV7/Aetee/dad1W ySJF2jVpNojyLmZRBwgRhCiFhWhU767dvxjSggBIZD4d/Ov/9Hjy0d9CiAAAECIXvR0d5qn7S+nV ZhCiGhQ5CMiCoXctmXqJzOoMIYq+EOWwEJWyEJ1kIfqUhegzFqLPKaZAiGqEiAPHq7gNfpSWlnZb 586d7+Ug8oG2bdt2aNOmTScAEgH5vcrvtlOnTq34d/w//Hv+AYQIABDVd2iDBg3S40GIFrMQ7eMA yw1jH9HLkNPxuSY9JCJMNceUUu9mynaDcKnHjn3EuqdFTUfkI9ck/ZrtNdukDjXpptFYi7qa7XdE qYu+zlYoZbU5z7lchjY19OhZlSXi+gbQC5H384FbIETxJUQSMErgKB/Qe/LJJxuwEN0tUsSBZesO HTr8EYBEQH6v8rvt1q3bXfw7/gX/nq+R7yXOmDHjvxC4AVB7yLdLhbS0tIZJ9w6tW7fu/sQSIi/B bmhwbx6U2x+nHhsNITIXALWeRu6k3tvDkQMHgTSbZxSSn9tyObepvix+1RdCVBtCtJyFaD0L0RYW om0sRNtZUmIJhKjqmSoBY/C5+m3+5w0cTP6SX1yNmds5uLwDgERAfq/yuxUZ4t/x9cF7+vJUu6cB iMP3TCC2ko+zQoiiJUSHWYjKyZltStAuEmJ7fDAo1x2nH0KWqx4Xkq4hsNbSmFszZK73NpP8dGlb bbfKs4oa8VLzUM5xrHsNue+a9JC9WxpynHme0gY1/+2+XBb1s7h+ftbX8roB34EQxZ8UBYfNfY3b oS7zPZl/IUElAIkE/25/GPz9Xi2xAobLAQAhghCFLUTmVAffZnKiExlVJpRA3XchMgbtNQG9UVxq yuMt0DeTolDxcWpXL+WybtPQ9ve7vhAiCFHqCpH0Ekn95S/qIkYyhA6ARIPv4yslRmAuExlC7xAA EKKUEaK9HGA5YhAiN+eMsRrmxgH58sAx+uB9uXLuckUkOswNbjcIUU1eVumYbdf3fljW0W4Y2TZy 12YW9dGEYYwhT5ESx7Z3LJd1m455xLDd9/rqhWhMufd2Au5QhWhdUIi2shBtY0mJJRAiczESJJgE INHQfr/yW4YMAQAhghDZBbuGQDsUh3ksCS1EkQX6qiQG6uWbEGnl8luIvNQXQgQhSm0hAgAAACBE SS1EesmplhQz5qaZHhcSkLsJ3lX5ibYQGYaQRSWYNbaNq543L+XyIES+1xdCBCGCEAEAAAAQogQT okUsRHs4wHLF3DTdUKpXtun3jwl+X0c97sG5wf1q4M8BeU7gnFJ6xbAAgPWxZJ6umrehXLohe2Z5 avlVo5bHWL/gvpBz7NrKIg1d+lZ5Vm2vqqeXcinHqm1nEKIcv+sbIIseNAjRHhAVIEQAAAAAhAhC VBtCxOSYLhJglBo1MDYfMmcqRCboxcckXS1gn5tmXy5XQmSQMcv6eZXHOqarzbk51lQobcvlRYh8 qK9Tu0OOoiZEg1iIcliI1rIQbWYh2sJCtJUlJZZAiAAAAAAIUcoJkaWYGIP8kGM4KNaCZzM5kW2G 4NrYC2QWgNuJReB8uzwtg31zUTMtj2dZsJADEzHRt6fbcnkUokjrCyGCEEGIAAAAAAhROHVr0KBB euIKkV9YB+8AAAgRAAAAACFKYiGqxUbVCVEWC1EpB1i1Qyn1UoRoWa2VA4DE4u8sRANZiJaxEK1h IdrEQrSZhWgLS0os6QkhAgAAAKJKixYt+gpt2rTpCiGCEAEAIEQAAAAAgBBBiACAELEQLWMhKmEh OsFCdJ6F6AIL0WcUUyBEAAAAAEh4IcpkISrhACva7P6ikorLtlIRs/rIFgBC2HDqUOB3IsTiN5nI QIgAAAAAACFKICGSAHdZyXyaVPA4zVnzMgCmjFn2MG0+fZJ2fvYfSJELIfqAhSibhaiYhWgjC9Em FqLNLCmxBEIEAAAAgMQXok9YiL6gqLH780raeeE/lLl1Cq3aM5o+o8MAmDIx/zEq+mQ/bTt7kXZ9 VhH47UTzt5nIQIgAAAAAACFKICGSAHfepglUuGcUXaBPADBlQl4aLd+1lTYe/5R2fnoJQgQhAgAA AEAyC1FaWlqzeBGi3SIuUWLHBQ7UTn1Os9eOZiEayYHvQQBMGZ/bnRauL6KiT07SVukl+rwyqr/N REYToqUsREUsRBtYiDayEG1iSYklECIAAAAAhO0ldevW3Z8SQvTpJdpw/FOaWTSChWgEfUr7ATBl 3PJHafaqPCrcf5S2nCmnnTJsDvIDIQIAAABSmKT+DlEqCdH6Y+dp+urhtJKF6DztA8AUEaKZK3Jo xd4jtPn0FxAiCBEAAACQ8gQ+T8PUq1cvF0IUJSFayEK0iwOsaLGdhWidCNGqj1mIhtO5yr0AmCJC NL0ghwpYiDaxEO1gIYrmbzORgRABAAAAECIIUQIK0Yo9H9PZylIATIEQeReiJSxEq1mI1rMQbWAh 2siSEkv+CSECAAAAIEQQIi9CNIwD390AmAIhghABAAAAAEIUcyFawEK0kwOsaLGNhWgtC9G0gBAN pTOVOwEwZdzyRwJClM9CtJGFaDsLUTR/m4nMkxAiAAAAAEIEIUo8ISpgITpduQMAUyBE3oTofRai xSxEq1iI1rEQrWch2sCSEksgRAn3Uv3/+vfs+YvMzg9tyOzcaRMAAFgx5bG0j9q1a/cVPNMhRBAi 34XoIw58twNgCoQIQgSi++yfMWPGfw198slH1vV4/ouzucsJAADMODY3g7L/2vaUxIt4rkOIIES+ C9GHdKpyKwCmQIjCEKLdLETHWYjOsRB9ykJ0gWLKP/MgRIkkRHx9Lv/w8ccf29z31Qt05AgBAIAZ 5Zs3ixCd5ljx2/xsvxI9RRCipBei+SxEO+R7QVFiKwvRmqAQ5e8ZQicrNycFxQMbkvYDvX3gAsft wBkRomksRHksRBtYiLaxEEXzt5nIQIiA1+e+BDQS2Ax+9NGnA0J0+DABAIAZ5Zs20dJ2fznLz/Yb +LlxNf/zMjzbIURRqVurVq2eS00h2hQmC+iN5nWqZUN4OHNTBOlFxrQ0pSxpH1VvLx54q0GINgGX QIi8CdF7LESLWIgKWYjWshCtYyFaz5ISS16EECVS79BX+/fvf9UH3bo+DyECADgJ0ZIH2pzjZ/tN Ei9K3ChDbvE8hRD5XrfafDFWC9HEoBB9TlFj63lViAbTicoN4VH6IjWpoxeiOmlDnI9t/iIVe93v AlV8mgyc57jdd3yoQ7wxVhOiPSxEp1iILlRE9beZyDyZAyEC3oWIr9E3P+jWrQeECADgQojOP/nk kw34ufE9CBFICSHazgFWtNjCQlTMQpTOQpS3ZxAdr1wfFkXVonErNanuKfoLpZsdX9pDkYUeVOR1 fwQU6YRorm/pHo9hHWoLTYhyWYjWsxBtZSGK5m8zkYEQgTCF6Fvvde36IoQIAOBSiG7l5/u1ECIA IfJTiEoH0rGKtWGQQa9rEtT8BZo68JZq6eicaXJ8yQuKLLxARV73R0CRUrYmAzN8S/dYDOtQW4xd 3g1C5EGI3mUhymIhWslCtIaFaC0L0TqWlFgCIUpgIfrkEwIAADMgRABCFFUh+oAD32LvlDxfHfw3 GThb9991mj/PMlBz7NTuhmF1CnKu0/5AOpltgttuoddL9Gl2zqzKRy8+s6vzD9lenZZGG5pqqF+R TvAMdVfO1/JxVQeT8+tYtJlZO1fTfVB41ywMIEQQIgAhAgBAiACEKKmFKJeF6GhFkWemVAvALfRa iWybRa81N24zHmsmC7Mc9wfSUYSoiWEhh4cyq/JZpROfWdX5q9ut0ZdZPUdLvxqdEM1yVUc3bSFi NqWiyF25uw8M67p5BUIEIQIQIgAAhAhAiGIuRPNYiLZxgBUtNrMQFVUL0ftUVrHKI+/TQ9U9G89S YXD75O6qBMzQn1PyrNKDVHOO6/2Zf7aUg4cyq44pHNjANH91e5VMaHWeoUicul1/jpa+WVl09XSo g1X5dHWrLoN5G1e3c/dwrpt3RIjSWYiWB4VoCwtRNH+biYwqRCtYiIpZiNawEK1lSYklECIIEQAA QgQAhMiDEC0vfY+OVBR6I/P+6gD+toHTTbdXBfHKOSwLt1ntc7NfTduYbxBVONT9OiGyK1ed+2mS yTkPZbqsv20dplPf5qH5WO8zClGh9+vkAxAiCBGIoRAdOkQAAGBG+caNECIQm/dTXHyHKOZC9C4H vis8Mam6J6gB9S1R971bE8Qb95U8o8jCMxzgG9J12q8KUXfzMuuFaJrjdrsy64XIuiy69GzroOZj hwiRsZ2t2jv6QIggRABCBACAEIEUej/VrVt3fzwI0VwWoq3yvaAosYmFaDUL0dSAEA2gwxX5HhhA naqD/qdppWG/GsTfNnBqzb6SpxVZCD3PcX/mHxUhMi/zSp34THXcXsVUpXdGhCP0nE6Z1mVxXUd1 ny1/ZCEyK5tRjPI9XrfwECGaykKUw0K0joVoMwtRNH+bicwTECIAIYqY0r63VT/r7uxb4LgdAAgR nqe19AxP3g+zpqIQ5ZS+Q59U5Lons7WLoF6Tgr/TCu28kr8rsqBsd7tfzbd7f9OyrRj4S0VUJjtu r6J/jeDV+SWLRug5nTKty6JLz64OTvVzQC1PFa1posc0wmHs8r9BiDwKUSYLUQELURELUTEL0RqW lFgCIUoBISroS3c6PH8TVRqsxCerk1K/ThPitszJch08EfJ77ERZZsdN6FR9TNoECA6ECEIEIYor IepPhypyXDOhex33QhSQieC5JU8qQvAkFRjTdtqf+QdFiN42LVuBTnwmmm4POVfNt84faIJDWsY2 0O2zrcPbBvHK8dTuoXmHn4YXIEQQIhAjIerT+wIdPEiuyO/jLER98sl1enFEaZ/bTOtgtb1WGd/R 3buw4/iEvBaRtIPpNVKOSxufxO0RJco3bIAQQYggRNESomWlb9PBimyXvEkdFXkYb3HceFWaur/p 8lyH/TohetM03/yBNyuiMsF0u/78CdSneR3Tc3T5KeUZbxBC3TkOddCd2/wJyjepf3V6JU8E5Kpj pnqMWt6bqU9JtodrFx4QojCEaFdQiM6yEJ1nIfqUYgqEKMWE6LY+VJpEQV9cio9DOS3Lql2nFBSi OnU6UhaECEIEIYIQRSJEGSxEW+R7QVFiIwvRqmoheosOVCxxR+Z9ilT0c3dcnftoXHD7OJPepcYD x1afZ7vfRd6q+Kjp1my/mRo3t/orXk05qxhLr1od25zTMcnHuY79FGEyp/rYkser87A9LsqIEE0J CtFaFqJNLETR/G0mMiJEA1iIFrIQ5bMQrWYhKmIhKmZJiSUQIggRhCjK6HrobqNB+SkerKui07Gj 9fWDEEGIIEQQovgVojc58M1yhRrsd8y0O/Y1XeBfc+yYEMnQp2OzP/P3ihC9Zppv/sCbFGEYY7L9 9yw9+uOqBCeN8k3rYVWemvqp+biro0n+AW6iV0sM+ZekmUiRyXFRBEIEIQKJL0Q1khH8q73xL/p2 abgdDmUxjM9OarI6hh7rdchc+HUbT2l2f6CyaRO13J6lrbp8VSKlphUiCR7aVG2fkHTGdwyv7cx6 eRx+I3f26aO0q+F8CBGECEIEIfIkRIdYiD6jqLHxHAvR0Sohyi59g/ZXLATAlDEiRPksRKUsRCdZ iD6tiOpvM5GBEIGIhejAAXJF/qs1gXLjV6nU4fjSVxsHA9HGdGdjKwng4FV3Xj4NamwtDGnjao41 ik0IIWW0T7s6uH4136QOVts91G2ci7k/lu06Tgn4G7PUuLxmIXmHljeSNlXbR03HWF/ztutIaZb5 uaijIX2ra6UeF1JG4Ej5+vUQIghR6gnRZg6wosWGoBBNCQhRP9pXMR8AU8Ys70qTWYiWsRCtYSHa yEIUzd9mIgMhArUiRKaT+MdZCJExSNWLiRqk6s7RBd9VQlB9rE4uVPHQp20lN2raIT1GnoTIbd3U 7Up5lTbVBfG2ba8XLSuJsZICS8mMsE29C5Hxd2MQVsPvyUmI9NKolB9CBCGCEEGI4leIXufAdx4A pkCIvAnROyxEC1iI8liIVrEQrWYhKmJJiSUQIgiRnRAZg33zfWpAbNdD4HCcqTzYn6MbjuZRiNzV TQnWde2klMtOAGx658IRolD5CqdNfRAiY4+Yjfg5C5HzNggRhAhCBCGKKyFaWvoa7a2YA4ApECII EUimIXMmAbgaoFeLgMVf+G2Hj5kdZza8zP4cr+LjvW4WPUQW0uClh8hVm5uWKdI2jVyIQuvsYWig afom7QwhghBBiBKjbrX5Yqw9IepLeypmAWAKhAhCBGIkRK++coH27ydX5BmEyOF4feCbp98/rkNN gN5hnLf0HY/L0/d25DmfY1VWr9st62bcbjZnJs+uPQ2ikOexza3KFEmbGvJLG7ffsh1ct51FPqZY pB+yXfnvkDICR8rXrYMQxREiQkLTpk0HQoiiJERzWIg2cYAVLdazEBUGhWhJaR8qrZgBgCmaEGWz EBWzEG1gIYrmbzORESHqz0I0n4Uol4WokIVoFQvRapaUWAIhghD5KkR1OlCWKzkwO85sv/05sRCi rA42CxW4aH/1/FCRiFCIwmrTaAiRO/GzFSKdVHFZIUQQIgAhilchGp/fjaateRYAU0Ys/SuECEIE Uk2IXAfDDr0IpuW0SzvPsGhAFIRIKVPYQbmuh8m8fcIXonDa1L4drARON4fIWBbXUmwnRPp07mzc GEIEIQIQovgTooVbt9PY7Gk0ZNYIem/qEBoweRANmDQQAHp38mD6YNpHNGzeRJpWuIGW7SmDEEGI QMoIkaEXRZdHVcCuBbQhE/NdyI1V2saem2gLkTkOwb9FWY0BvmUvkqMQhdemekmrqYPbNtWXxyYf r0Jk0SMHIYIQAQiRoxDNZiHaKN8LihLrRIiOX6BFOw/SlIK1HPQuoUHT59H7U+ewGM0GgD5Iz2BR XkijF+fRrLXbKGf/cSo+VU7rWYii+dtMZB6HEIHaECIrlGA7rHk2up4cu4A2z/mbQiGBv03ajRsr y1/HeMicx4DdTTrhCFF4bWpzjos2jUgQHYTI7PcKIYIQAQhRrQvR+vP/CQS3EuTO3bQ7IEXjlq2k MUsLAAgwNnsFTchZRTOKNlPm9v2Uf/gMrTnzJW24UAn5cRCieSxEy1mIVrIQFbIQrWJJiSU9IESJ K0T79pErcnu7EKKx1ceX9lakoXeuPq2xHUzP0TAL+kPSMKajDifLtapHbkgAnzZWto+tliU1H6s6 eK9bTfrG+qppmbWF23roZMKunZzyiHWbGvNz2wbKeaa/DWPb2tYBWFG+di0taftnCBGAEPmFBLVr z/6bVh77NCBF0lO0YOtemr+lFIAAC7buCYjQkpLDlHfoFBWd/CIg0hAiCBGIAyECYVMTmJsE5apo Nu5NpSnTFtYiAyBEAEKUtEIU6CX6tCIgRatPfB4QoxVl56jgyFkAqll59HxgaKX0JsowS8iQCyHK ZiHayUJ0jO+rMyxE51iIzlNM6ZELIYIQASt0c3t0EqDvXUkFQYAQQYgAMH0/xcuHWWexEG2Qnpwo sp6D23UsRevO/yfAWg5417AgAaAhvwnt9yG/FfnNRPt3mchoQjSXhSiHhWgFC9FKFqJClpRYAiGC EAGvw9CMc26Sv3cIQgQhApHRtWvXFkJaWlpDCFG0hOggC9EFignrP60EwJFY/R4TGQgRiFiI9u4l EAvGWC7qkDYmddpBL0TL8buIc8rXrIEQxdczPHDvyMdZIURJIEQAAAgRgBABACBEAEIUd0K0Xnpv AAAJA4QoMSQkXpBAhq/RZXyNrh7Qres/NvXu9Vnlnj0EAEgcIEQQIggRhAgAYBCit1mIMliIlrEQ FbAQrWAhWsmSEksgRHr69+x55ahHH315bPdHXhvzaLfX44Wxj/yt3+hH/vbGyL91eWdyu7bZhY90 /feeIYMIAJBAfDiYPisqoorSUggRhAhCBCECAECI4q83SIKFoU8+3m112qNf7hs+jAAAwE+2vvIy bev7Kv179y6WohIWlz1Ro3xNMYQIQgQhAgBAiCBE3ufofPj4449t7vvqBTpyhAAAwE/KZs6gTSxF n27eTP/etYsqpadIhtJFgfJiCBGEKMWEaCYL0ToOsAAAiQOEKP56h/r37/+1wWndngoI0eHDBAAA flI2YzqtfemfdJxl5Ytt26iipARCBCGCEEGIAEhtIXqLhWgOC1E2C1E+C1EBC9EKlpRY8gKEKPBM bdeu3VdYiL7+Xrduz0GIAADREqJVPZ6ngwUFdGHLFvrP7t1R6yWCEEGIIEQAAAgRhCgcIbrqvW5d X4AQAQCiJUQrnn+W9uYup/ObNtKl3TJsTnqJSn0HQgQhilndGjRokB4PQjSDhWgtB1gAgMThMQhR 3M0f4vp/84Nu3XpAiAAA0RSi0pxldG7jBggRhCg56labL28IEQAQIghRFIXok08IAAD8RISo4Lln qHQZC9EGFiJZWEHmEcmwOZ+BEMUXXbt2bSGkpaU1hBBBiAAAihC9ubSYZrMQLT36OeWd/g/ln61k KaKYAiGCEAEAIEQAQIgAABAiCBGECAAQAyF6moUom4VoPQvRThai3SwwJb5TXlwEIQKpJUTTWYjW cIAFAEgcIEQQIgAAhAhCBCBEfgnRARaiTwkAkEBAiOJciA4dIgAA8JOy6dMgRABCBCECAECIIEQA AAgRhAhAiKIgRMUcYAEAEgdViJawEOWyEOWxEOWzpMQSCBGECAAQQyF6loUoeymdW7+OLu3cQZW7 dxGJFPlMedFqCBGIzTs0LS2tGYQIAAAhghAlI6V9byPt2xl39i1w3A4AgBCBFBSiunXr7ocQAQAg RCksRAV96c6gHFiRqNJgJT5ZnZT6dZoQt2VOlusQNhM6KfXvRFkQEggRhKjWkA+yCk2bNh0IIYqS EE1jISriAAsAkDhAiOJYiPr0vkAHD5Ir8vs4C1GffHKdXhxR2uc20zpYba9Vxne0vQbVdByfkNfC G+MpLaTuHSkr6esd/5RNS4cQpWovSvBeFCmCEEGIAAAGIZrFQrSYhWg5C1EuC1EeS0oseR5C5J8Q 3daHSpMoeItL8XEop2VZteuU7EJkKYYQorgSoqUsROtYiHawEO1iIdq923fKV0OIIEQQIgAAhAhC BCFKfiHS9dDdRoPyUzzo1oQo8FtUe4ogRPEnRGtZiLazEO1kgdnlO+WrV0GIIEQQIgAAhAhCFH9C VCMZwQDV+Bd9uzRM/vpv2xviYeheVsfQY70OmQu/bmZDvNy1iVpuz9JWXb4qkVLTShsffpuq7ROS jtImntouLKGBEEGIIEQQohQSonQWotUcYAEAEoc0CFF8C9GBA+SK/FdrAuXGr1Kpw/GlrzYOBqiN 6c7GdayHN+nOy6dBja2FIW1czbFGsQkhpIz2aVcH76/mm9TBaruHuo1zMffHsl3HKQF/Y5Yal9cs JO/Q8kbSpmr7qOkY62vedh0pzTI/r3UcpxeiAx7bB/gOhAhCBCGCEAEADEL0BgvRzKAQ5bAQLWch ymVJiSUQIh+FyHQS/zgLITIGxXoxUQNp3Tm64Lsq4K0+VicXagCsT9tKbtS0Q3qMPAmR27qp25Xy Km2qpm/f9vqA30pidOnZyJhfbepdiIy/G4OwGn5PECIIEYQIQgQhghABkNhCtISFaAcLURkL0SkW ojMsRGcppkCIak+IjMG++T41ILbrIXA4zlQe7M/RDUfzKETu6qYE7Lp2UsplJwA2vXPhCFGofIXT pj4IkbFHzEb8IEQJLERrWYi2sxDtZCGShRV8pnwVhAhClGJCNJWFaBUHWACAxAFClOpD5kwCcDVA rxYBt0Gt03Fmw8vsz/EqPt7rZtFDZCENXnqIXLW5aZkibdPIhSi0zuEODYQQQYggRBAiCBEAIM6F qB8L0QwWokUsRMtYiHJYiJazpMSS5yBEoUL06isXaP9+ckWeQYgcjtcHvnn6/eM61AToHcZ5S9/x uDx9b0ee8zlWZfW63bJuxu1mc2by7NrTIAp5HtvcqkyRtKkhv7Rx+y3bwXXbWeTjjNo+HSjL7W8a RI2y9KlBIVrCQrSGhWgbC9EOFpidvlO+qhBCBCGKTd1atWr1XNwI0XkCACQQacsgRBAij0JkG9Q6 Bb9m++3PiYUQZXWwWajARfur54eKRIRCFFabRkOI3IkfhAhCBCGCENVK3Wrz5Q0hAgBCBCFKASFy HQw79CKYltMu7TzDogFRECKlTCHi4BZdD5N5+4QvROG0qX07WAmcbg6RsSyupRhClDBCtISFaA0L 0TYWoh0sRDJszmfKCyFEIIWEqF1QiAo5wAIAJA4iRK+zEE1nIcpiIcpmIVrGQpTDkhJLIETxLkSG XhRdHlUBuyYTIRPzXciNVdrGnptoC5E57oJ4Y1mNcmXZi+QoROG1qV7Saurgtk315bHJB0IEIYIQ AQgRhAgACBGEKGpCtG8fuSK3t0NQL8Ht2OrjS3sr0tA7V5/W2A6m59C+sbYfLk0bqx2X6/xNIV26 Dmk3blyz/LVSVqs6hFM3yyFzpvWzxk06IeWybG+VcNrU5hwXbWoriE6/x7Ed/EkHRIWyqVMgRABC BCECAECIIETehcg66A9JwzIobkyDcve5DvqrJKRGlqIjRIqMGeqrEwRLWfEiLyYS4EqIaqlNjfm5 bQMIUYII0WIWomIWoq0sRNtZYHb4TnnhSggRSC0hmsJCtJIDLABA4gAhShIhAmFTIwEmYqGKZuPe VJoybWEhuSC5hGgxC1ExC9FWFqLtLETSS+Qz5SshRABCBABIECGaxkKUyUK0lIUom4VoGUtKLIEQ QYhqC93cHp0E6HtXUkEQIEQQIggRgBBBiACAEEGI4kuI9u4lEGXGuBjeJb1DKdAWeiFajt9GkgIh Akn5Do2H7xBBiABIbCFKZyFayEK0hIVoKQtRNktKLIEQQYhqlzGWizqkjUmddoAQQYggRCBh36F1 69bdHw9CNJmFaAUHWACAxKE7hAhCBABIPSF65ikqXbSIzhUV0aUtW6hy2zYikSKfKV+xAkIUX++Z 5P0wK4QIAAAhghABAACECECIIEQAgDCE6DUWoqnbD9OCI5/T4pP/oSWnK1mKKKY8uxxCZC5EewgA APykbOpkCBGECEIEIQIAQIgSRIj2cAADAAA+UjYFQgQhghBBiAAAECIIEQAg1YUoK6tKiDZvpsqt W4lEinymvKAAQgQhSi0hmrT/HBWcIwBAAiFC1JeFaAoL0XwWokUsRItZiJawpMQSCBGECAAAIQIQ IggRAABCBCFShKgXC1EpAQCAn0CIIEQQIggRAABCBCECAECIIEQQIggRhAgAUCVEfYJCNI+FKIuF aBEL0WKWlFgCITIRot4sRKUcwAAAgI8EhOjpv1NpZiadW72aLm3aRJVbthCJFPkMhAhCBCECAECI IEQQIgAAhAhCBCGKdt1q8+VtFKJ8DrAAAImDJkSTWYjmshBlshBlsRAtYkmJJc9AiCBEAAAIEYgq IkJC06ZNB0KIIEQAAAhRgghRCYEosKwX3Sl/KW3Ui+NDtAdILcqmTIIQgeR7h6aiEOWdraTcMxUA AAW5LyBEECLggtHtA8NG7uyVjbYAqStECxfSuVWr6NLGjVS5eTORSJHPlOfnQ4gAhCgaIjR18W7q 3XU8AMDAlEW7KPf0fzyJkSZEk1iIMliIFrIQZbIQZbGkxBIIEYQolpT2ahQQorTRaAsAIYIQAQiR j0I0kYUoT6QliiznYG/05LW0aPI6Onf8SwBAELknRkwooqXHyinn1CXKZSlyc09BiOJciEo4gHFL dtUwsECvR0k2DWpUNXm2ivaUZXFeVnv1uCpJ0AmDWfrBf6+jDTuLND3b8o6mNCW9Ou1HW7dBsOfH qt5aOczQlc1FWq7bxJiOob0AiDVlkyFEAEKUsEIkAV728Ys0YvxqyuLg7ywHgQCAKuSe+GhkPi04 cCYgRctlGJ0LKYIQxbsQ7SbXBAPvtF4v1wTmukD8ZQ7E1XNG6UUjhEY0KNsk/faGAL/9qMjSsyov p2slMHf2Wmqo/1KDUBlFpuo4o6yZl81dWm7axFLAQq4FALGjbPJECBGAECWqEEnv0OKjn9PQ0QVV QnTsIgAgiNwTH3y4hGbtPEyLjlxw3Uv0KAvRqyxEE1mI5rAQLWAhWshClMmSEkuehhBFLET64FsJ 3LM14dALSbUc6IJzRQYMQbtOJkwCeq/pOZc39Lzqc6olzFg2VVhq8tYJlJa+hZR4Scu+TTRBDE0n VOgAgBABkBRCNIGFKFd6cqLEMg7wMg9/SkNG5AaCvzMcBAIAqpB74p33F9DUTXtpwcGzlH3y37Rc Fh9xuK8gRMkiRNbiUbNPEaLqYVyGHg91n0467NIPJz0rgTL0NBnOMU3LJm9NoHQCUr2gwlLLXjZ3 aTm0iYN4AVDrQrRgAZ0rLKRLGzZQ5aZNRCJFPlOelwchArF5h8bLh1ljIkSfnKfBHy+nrEksREcv AgCCyD3x9rvzaNL6Epp/4Axln/gSQpRSQqRJhGFYmoUQaTJiJgWmEmGbvs/pVfcQuRMcq7xreqD0 edTMZ3JfD/O07NtEP4TQRBQBgBCBGNO1a9cWQlpaWkMIUbSEaB8L0VmKGstOshAdYiEallMlRGUX gU+cPlIOIqS2r2FAiAbMpUlrd9P8/SxEx1mIzlQ63lciRL1ZiCawEM1mIZrPQrSAhWghS0osgRCZ CdHLF2j3LnLF0qBEtB9psn9kzdCtwH8vqRGkpaFpaVKQNspt+hGkJ70nhuNLXw5Kz8tLXKQ10mHe kjEdu7J6TMu2TYz5KWLk9poCECXKJkGIUrYXJfgsko+zQoiSQIgyOfg7LYE8iIhTHMhv3rGChi95 AETA9p3r6OThLwLtWVvXMhNClNpCNKq9pURo+2rkwyhIZlJgEAa79H1Oz1SgdHKh5LPUYkEGC9my LavXtGzbxEaMTMsFAIQIQIiSQojGsxAt5wArWmSzEC1kIRokQjRxLXolIuQUB/AnDn1GuesmUuGe UXSBPgFhsHTre7R6wwI6euB8oD2lXWvjeso98RYL0UQWonksREtZiHJYiJzuKwhRcgiRs0Qo+5Yq Q9Is0jEG7VqvTWj6fqfnogdHTcump8m2J83seI9p2baJKXbiCEBtCdFKFqL1LEQbWWA2+U55Xi6E CEIEIYqmEMlf40H4nPjkcyrjID67eCwL0Uj6lA6AMFi6dQAtXzWL9u86HmhPadfauJ6RCNErLETj WYhmsRDNYyGaz0K0gCUllkCIIhEidViWPtg2F5KaoWE1wbxhaJduGJj9kDjv6Wnlcik9xp4uXVoW PVCasBjTCekt2xVmWi6GCRqH0tnmDQCECECIIEThCNHhchABxw9+RodKTlHWyhG0cs8IOk/7QBiI EGXlTKSdGw/S4T1nAu168pMvYn49IURJKESvsBDt4gDGkZHO3/9Zoj/H6ns82vd0AsPAQtJn2bIo g2/pLVHm5Rj26eYWuci7jlk6S0KHxaWNDCctuzZZYvMdo9BrAUCs0QnRShai9SxEG1mIZNicz5Tn QoggRCkoRDkcYEWLpSxEC4JCtHDCWg46y0EEHN1/gfbtPE4L8oaxEH1M5ypLQRgs2fIOzckaRZuK S+nArpOBdj1x6IuYX0+5J0SIJrAQzWUhWsJCtIyFyOm+0oRoHAvRTBaiuSxE81iI5rOkxBIIUQRC pErEEpNv+JieZzLZX5EOVRKq07RMy8f0RrY3lR5VVnRpGWQpZAEER3kLFRpXaTm2iYkU2bYfABAi ACGCEEGIYooE7GX7P6W9O47RvNyPaMWeYXSmchcIg8Vb+tPMBcNpw+rdtH/nCQgRhMhnIdpJTuh7 TnYCAIAtZZMmsBA9yUI0n4VoBQvROhaiDSwwG32nPHc5hAhCBCGKphBJ0JlsFPdtVv3XxCZ9t0Yt n+MHP6cj+87Tnu3HaO7yD6lgz1A6XbkDhMHiLW/TjPkf0/pVOwOCWbbv00D7xvq3AyFKXSGq6TlB oAcAgBABCFGtCtE4FqJlsjx2lFjCQjSfhWhgOEJUMICaOHxfIpoC4pb0TkqZOs2NoRB9SKcqt4Iw WLzlrbgSovEsRBksRItZiLJZiJzuq0eCQjSWhWgGC1EGC9FcFqJ5LCmx5CkIkbkQ7eQAxhZlcv8S p2MBAICFaCKECEKUhELUoEGD9FQTogXj13LQ+YV78l0IUZ+t3tK0y+O2AVQURhpFfZr5Vx4bjh34 nA7vPU+l21iIcj6k/D1D6GTlJhAGi7a8GRCidYU7A4J5ZO+ngfaN1rWzQu4JCFEqCpE2uf+vlIVA DwDgVoieYiGaz0K0goVoHQvRBhYimUfkM+XLIUQQohjVrTZf3gkpRGHKSlzkETUhGkwnKjfECUPo 4UA7tqV09b+bv0jFcVPGGhZteQNCBCGqRSFyT+WOHQCAJCR8IZrHQlTAQrSWhWg9C8wG3ylfngMh iiO6du3aQkhLS2sIIYqSEI1lIcqW5bGjxGIWonmKEB078IV7VFlpzLLi5dx4ysMnju7/nD7Zc55K th6jDBaivNKBdKxirUcy6PXmWg/bX2iq6T51u9k2MwZTZ12awf9u/gIVeS6jl3zDI4uFaPq8j2nt yp0BwTy859NA+8b6mso98SYL0bigEC1iIVrKQuR0X4kQ9WIhGrPtME0//DnNOfEfyjhVyVJEMQVC FF0hqti+nXa98RpteObvAIAkYiff13J/CxAikNK9XykpROPW0DEJOt2SZ5AVh+OLXtWGrnWjqbJt XDf9EDtDGlM72AzFe3VL1XHVaTSj1/P053QeZ8xXOU/FWA67+uSZDBPskBHYd3TfZ/RJ6Tkq2XI0 IES5pR/Q0Yoib5Q8H0i/SfNbAmk/lKnun0WvBSSkDU2x3eaGgfRQQIiep1VeyxhRvu7I2tKPhWgY rV2xg0q3ihCdD7Svp9+nD8g9ASFKMiHq9a8LJH/9jZCKbdvo0tatVNi5Ax1dMI3OFGQCAJIAuZ/l vi7fuDFwj1eKFLl4JpRNGA8hAhAiCJEXIWpGTRpbyU5QlsIQImOaboTILg+1LMZ06phIUagQvUdl FYWeKBzYgNO7nyaXPFvVtt3fD+6bHhQQheb300Mh256lwuC5TQY+WyU9kl71+fLvkt77QSF6ll7r XnP+Q5nBsljm34BeKzErC+drWk45vtBzO2RteQ1CBCGKWyGSAEkCpc83bKCVD3Wgz3cUUcWJEgBA EiD388qHHqRTq1bRF3yP/4fvdQgRgBDVshCN2XuOAzCKGotOXKK5B6uEaD4Hf0f3fe6eXIdFFQKS UHP8qt56oWjSe0tw3xZ6TZGZh8Za5MHStcpYhrHdLPPX0lHzrcnTersuzeo6ZATlIrQcUzpUHVe2 9zM6VHKOdm9mIVr2IS0vfZeOVBR44N2qPLrLeenUNyAWf6RJ1ftdbit5mm6rFhyr496trk/VMdr+ BtS3REmj+7uG84P7XZZlUnfjMe7IFCGaO4zWFOxgwTzGonk+0L6efp8+IPfEm+/MpbEsRHP2naGs Y1/SktOVjveVCNHLLESjWYimsRDNZiGaw0KUwZISSyBE0ROif2/ZQmeLi2kFB04QIgCSS4gKOrWn A8uW0fk1awL3upteomohmjeXzhXk06W1a6hy/ToikSKfKc9ZBiECEKJkECKdgNjt8yhExnSt01Yl rBtN0Z1jts9aiDSMQpRT+g59UpHrnszWgfRvGzg58N8rBv5S99+fVEwOCkdrmlh9nsm2kr9XyUzz v9MKy+P6UyfDMVp+nTKVNLr3N5z/SxYih3yrz6mpUyBND22RuaUvhAhCFNdCdHHTJjpZWEgrOHCC EAGQXEKU3/GvtCszM9BL9OXmzRAiACFKKSEau4aDzs/ds1wvK4UOxxcaxES3f4y+V8Z1HlbnOear CE4d+2Fzk4PpTA4ZXteMXltek8+RPZ/Rwd3naNemKiFaVvo2HazIds34QG/KzdSnJLit5Img2DxB +YFjJlCfgIT8gcZXn2eyTTuv+5tK+sbj3qSOurSzKX/gzUEBm2CShna+Vj6TfDP/YNmOHTOzPbXF wi2vBoSoOH8HC+YxFs3zgfb19Pv0AbknIhWidBaiWSxEs1mI5rCkxJK/Q4jMhUiCmwio2LqVyjds oOMrVgT+kgwhAiDJhKhDO9o2bx6dXLmSLm7cSJXbtjk+FyBEICnfoWlpac3iRYiWcIAVLbJYiDJY iD7QhEiCTrfkvKPIyjtU6HB84St31IjJK1v0+1WxeXCO+zysznPKV03XSYiq09IP7avhDnot5zM6 UnqBDu46S7s2llFGtgjRm3SgYhEIg4VbelcJUd522s2CeYhFU9rX0+/TB+SeeIOFaAwL0WwWokwW osUsRE73FYQoNYToWEEBhAiAJBSiPBairXPn0okVKyBEILWFqG7duvshRCkiRC7KbpemJk6TDEKU XfoG7a9YCMJgwZZXIEQQIggRACDxhGhuBp3Lz6NLa4qpct1aIpEinylflg0hiiPkg6xC06ZNB0KI oiREo1mIFnOAFS0yWYjmBIVo3pg1HHR+5p5l71RP3q/TiKXC4fjCXjUScVuvLfr9o/Vi4zoPq/Mc 852jDJm7g/ou+8xb3YNMerAmjT7ZLEQ7WYg2lNGcgBC9Tvsq5oIwWLC5F03LGEZFLES7Nh5l0TxH h0suhHWNIkHuCU2IZrEQLWQhWsRC5HRfdWMh+hcL0SgWoqksRDNZiGaxEM1mSYklECIIEQAAQgSi /p4JxIIiRRAiCFF0hEgnLtIL45cQqTJjVv6qfKuPD9b1odHqMVuobyNrIVpa2pf2VMwCYbBg88sQ IggRhAgAACGCEEGIIESxF6LDJZ+5J1sRIivaz6k+fqVBTHRpqWKjnCNMah+abvX5Nuc55zunaqU1 G6qPd6irHPfJ7gt0YMdZ2rmehWjphzR9zRO0pPRVEAZTC9Mofc4wWp27nXZuOEoHdp4LtK+n36cP RCpEI1mIprAQzWAhmslCNIslJZZAiCyESIKbCKjYsoXK16+nY/n5ECIAklWIMjKqhGjDBqqUbxE5 PBfKxo+DEEGIIETREqJRLESLZDW4KLGQhWg2C9H7cSxEh0vUnpgqOo3+zAchCt2vLpTQN9tNfWuO U4Uob9lKmjT3bRo5rTcNm/wvGjrxJfpoYk/gwNBJL9HHU16m0dP70NzZ86k4byft2nis1oVoNAvR TBaiBSxEWSxETvcVhAhCBACAEEGIIEQQokQUotHFdFiCThAWn+z6NCBEuzYcpeLcHZQ5K48mj55D oz+aSiOGTKLhgycCB0YOmUxjhk2j9HHzaXHGSlqbv4tKNh0PtKu0b6yvqdwTECIIEYQIAAiRayHK mEPn8nLpUnERVa5dQyRS5DPl2RAiCBGEKGpCNJeDv092XQARcGD7uUAAv7FwL+VmrqP503Np5qRF NH1CJk0bvxA4IO00a9JiWjgzj/IXb6RNq/ZT6aYTgXY9tPPTmF/PuREI0UssRCNYiCazEE1nIZrB QjSTJSWWPAkhShohKunXqLpnunm/7KidA/y9PrgGECIIEYQIQuSDEI1kIcqS5bGjxAIWolkQIt84 uOM87dt6mnauK6P1K0qpMHsr5S3aEJAj4A4RoVUsFCKVO9cfpf3bzgTatTaup9wT/ViIRrEQzWAh ms9ClMlC5HRfBYRoMQvRVhaiT1iIjrMQnWQhOkUxBUJkIUQS3ERAxebNVL5uHR3Ly6OCju6FKPPh Ou6C4+Je1FwbltukF5UYzq3z8OjEFCK1XhYkqjRYtXU41w3EkRAVFNDF9eupcssWx+dClRA9ASGC EEGIEl6IRhXToZ0XQAQc3PEpHdh+nvZuOU27NhynbWsO05aiQ7R59UHgEmmv7WuOBNpP2lHaU9q1 Nq6n3BPhClFPFqLhLESTWIimsRBNZyGawZISSyBE8SVEatCsiY7b4DopeohSUIjQQwQhghBBiCBE EKKUlSJh/7ZztG/rmUBQD7wh7SbtV5syBCGCEPktRHohaEQDi82Oy6aBTZyOKUl8IbIRwmQSIpBi QvR3FqI5s+lc7nK6VLSaKtcUE4kU+Ux59lIIEYQoNnVLS0trVttC9EBQiDJleewoMZ+FaCYL0Xua EEnwCXzhoATzIGJq8xpqQjSShWg6C9E8FqKFLERO95UmRB+zEE1kIUpnIZrGQjSdJSWWQIjiTIh0 smMROPsoDRAiCBGAEAEIUUR1q82Xd20JUcbIYg5APwUABJF7AkKUZEL08ksXSIKbCKjYtInK166l Y7m5HoXIedhcuEOvdHNVgsc4Bunp7UOHrdmJisWQN9cC4FGIasrfnjLNymuXhkndHAXUZZ28tLXz dq91G03d7YYdqueZ1Q3zmNwL0Zw5dCI/ny6uW0eVmzc7PhfKxo2FEIHke4fGixCNYCFaKKvBRYl5 LEQzIEQA2ArRCBaiaSxEc1mIFrAQOd1Xf2Mh+icL0TAWogksRFNZiNJZiKaxpMSSJyBEcSdE+oA2 dEhcTbCt32ctN/peJ7dzc4xBvZ5gkO76eJc9PmELUSNq3sRtWe3bo3t6JHXy3tbOQuShbmYCa1Fm nXhDiiBEAECIvAnRgW2fAgCCQIggRP4Lkd1qc4osGYJxNz0Q6jlmvRiOcqUG3GrQrAvE1SDdxRBA L4sqGAJ1Y1Bfk74+X1VyrHvgqtq2+tgw6uRnW3uvm7pdKa/SpjVpWP+OAmWFEEVRiB6n0tksRMtz 6NLqVVRZXEQkUuQz5UuXsBD9CUIEIEQQIgAgRBCixBQiXTCuBqzKdqNcmAfW9gswmIuXRWBtuc9h kQed5IT2LPklRH60h+uFK0zrFE5bhzcE0nyfIjm6dlLKVb3dWogAhAiAhBSi4SxEC2Q1uCgxl4Vo elCI5owoov1bzwMAgsg98ToL0XAWonQWogwWovksRE73lSZEQ1mIxrMQTWEhmspClM6SEksgRFZC JMFN+FRs2shCtIaFaHl4QmQxbM5quJyrINlERpzPcTNszj4PpyGA/gyZM+l9Mu3NcipricvjzOoU TluHOSfMtG4WImsh0aHDASNbsTA1hWg2C1EeC9FaFqJNjs+FsnFjIEQAQpQsQrRvy3kAQBAIUZIK kfy1NwIqNrIQrWEhWh6uEJn1KNj/Vd80gHYQDMdz3AiRo8R4WCY82kLkNv1w6hROW/sqRE5ziIxt bzXfCWLkWohYbE7ksRCtZSHatMnxuVA2FkIEIEQQImBgFnWQl0/DtykX7QEhghBBiJyGzdkMl/O1 h8jz0tdeelM8DJmLthD51kPkrqcsFkJkuQiEQ1uGLrDgcJ0gROEL0ZMiRLPoXM4yurSqkCqLVhOJ FPlM+ZLFtKQNhAjE4B3aoEGD9HgQoo9ZiObL8thRIoOFaBoL0bsiRMNZiDafBz6Q+887Ai+eDkPV 7UFJqtOVxiZ4vTT09Us+5J4QIfqYhWgqC9EcFqJ5LERO95UI0T9YiD5iIRrHQjSZhWgKC9FUlpRY AiGKYyEyDMvq/nAj27/gOwuRfQ+Bu3MinG/jJDkxHTLn0xyi6nKG09Y+CpFSJnURifB6JdFLBCEC wOU7tG7duvtTTYhmc/C3d/M5D2yg3g3th110GHrOY5rxQk3dGv9zQ5jndqUxuu0zq4VIt33B29Q4 sP0O6r0gjttkaNeQ6+u9bRKL2RCiJBUiCW7Cp2LjBhaiYhainAiEyOIv/haiYBVA69JwufKZ1Tmq VLhZXS2iVeaiIkR2dasqqyYT4dQpnLaOhhA5LtEdPFYvTh6GNkKIgkI0i4Uol4VoDQvRRsfnAoQo haUhmT/MmrJCtOmcB7QA30aIPjrnMU0jLBe3KrKwKQZ8pA/8G/9jg7fzNcF5YKZFe7EQmR0fVh1j 1z5jHgizPRIYCBGEKJpC5PrjobYBtM0iCU0amSzJ7G5hBc/fOnKzlLOb+UtKOmHNs3Gom/ky1m7r 5L2tYzJkzlg/h3Z2/SFdCBGECECI4kmI5sny2FFiDgtRerUQraY9m856YAY9WB3gn/V4rls20CuB gP92emVBtPIw5sXc+hblBMVIBMBLOjn/uD1w3oMfxaK9YtU+sbwO8YPcE68FhWgKC9FsFqK5LERO 95UI0YuLWIi2sBAd+pwmHfsPTT5RyVJEMeVxCJG5EMnwlwio2MBCVMxClBOhEIUE2NZ/ubcNoE2C +6rAvyZ9p3lJribdm07q99DbEBMhspYHUxHwXCdvbe2fEFktu224jrY9SugZ8iREs1iIclmI1rAQ bdzo+FyoFqJZM+ncsmy6VLiSKlevIhIp8pnyxYsgRBAiCFHUhOhjFqKNZz2gBPiezvOCEojPj1Ye +voEREb+WxUiX8objfaKVfvE8jrED3JPQIggRNETIgDcUSM9Ec7jAhAiACFKRCEaxkI09zRFjdnH L9HUA+dpgCZEG856QAnw3Rw/762qoWFtZwT+e0xbw3yUFzfojjfuV3lwSPC4IV1rztXSD/bwjHnx dtN0NXIc9uvS9qVNrPbZnDPEMG9Heq68tI+rstqfa5mPUpZkRROiYWt20+S9Z2jW0S8p41Sl433V NbtKiD5kIRrLQjSRhWgSC9FklpRYAiEyE6KeLEQS3IRPxYb1QSFaxkL0VwgRiDpWH371PI8LeBCi mSxEy1mIilmINjg+F8rGjoYQQYggRMkgRLM4+CvlINA9NYH8aDfHs7A0CgTSt1f904RGLB/a8aMd Av7AcUFhaHTr7SHB+rLq/PjfQ8qzgXoFezx6zbMor5a2Uib3dTTL06q9LLYP6WrbRq7ax4JlL95u P2yFpdXxOpjWMbmYBSGCEEGIQDxg+w0i9A5BiCBEECIIkX9CNIyFaP0ZD5j3MFQH7j3W64+f+5ZO hB4cUrNvWQ8tQO9Co3V5rK8Rl7kmZRjSRcnT6lx9Xrrz/jLDun7BY0LqYYdtulp7Gctptt283tJO +vI4tI8ZynUIqZvSnvo2CyOfJEDuCQgRhAhCBOID60Udwl2KG0RBiGbOoHPZS+nSyhVUuaqQSKTI Z8oXZUGIIESpJURDWYgyOMCKFrNYiKYoQlTCQaB7ZlB7ByHSHV8diFcF1eZpGffpA/GQMlQH8FUy YdyfrYkWC4q6ffRfqsrYfohN/RQhct0mihBZt5exrGbbHert+bjQNrGql3mbec8nGdCEaCgL0SQW opksRHNYiJzuKxGiHixEQ1iIxrAQTWAhmshCNIklJZZAiCBEAAAIEYAQQYi8CtG6Mx5QAnk3x2fU DCfLDtmvBNwZbrYHGawIiOsyuiz3YEWIXLaJTiZct5fF9sFK75dl/RzaJ5zjTa+T13ySAwhREgrR v1iIJLiJgIr161iIiujYsmwIEQDJKkQsNieW59BFvtcrN6x3fC6UjRkFIYIQQYiSQYhmDl1Nu9ee 8UBNID/KzfFaoH3LW7Q0ZP96evmWqoD75Qw324MoQmSV7yitN2iw+3PU4xq9sN59m9imbdVeNu2o SpFp2zm0j+t2NimPLi+v+SQHck9AiCBEECIAIEQQIpCSQlSbL29ViD5iIZrDAVa0mMlCNJmF6J0k FiLjMSGCFM9CFHJMpKLi4njT65S6QtSXhegjFqKJLEQzWIhmsxA53VeaEA1mIRrNQjSehWgCC9FE lpRY8hiECEIEAIihED1GpTOm07mlS+jSigKqLFxJJFLkM+VZmRCiOKJFixZ9hTZt2nSFECWFEK2i XWtOe2B6dSA/0s3xc94MBtpv0pKQ/etqAu45brYH0QSkzXSX5Qz+u2kZzNNu9MI6921iW0er9nLb jmZt4dA+JoxsU8e2XkteuN2kTb3nkwzIPQEhghBBiACAEEGIQEr2fkGI4kWIHAJ4V0JUE+Q3uuV2 95ITjhDZtokXIZJtxrYwP99JcCzbzOScahnyKqYQIggRhAgAACGCEAEIUbSEaLYsjx0lZihCNOOj VbSz+LQHptNfHb6L8NdByvGzFSEKSWsd/SsYcP9rtn7fkudvt053UI0Q2ZZVy7uOeR5u6+OYj009 atJnoXHcblMWQxls28cCTaIsVwh8fp2HeiUvck+IEH3IQjSBhWg6C9EsFiKn+0qE6AUWokEsRKNY iMaxEI1nIZrAkhJLIERmQvTPCyTBTQRUrFtL5UWr6Vg2hAiApBWiGSxEOcvoIt/rlevXOT4XykZD iACEKHmEqOi0B7Qg2UaIBirHz1KEyDItDrhnhealD+CVYwYqQuS2rKb5Cy6FyKFdNEHR1V2XPouP m+2z3gz5gG1AVIo8tI8dJumHls3d9UlWIEQQIggRABAiCBGAENWyEH3IQjRLVoOLEtNZiCYpQrSD g8BkZUSbGkmLal6KpCVze6YCmhANCQrRNBaimSxETvdVFxai57OKaeDmwzTy4Oc09uh/aNzxSpYi iimP5UCIIEQAgJgJ0RMsRNOn0bkli+lSQT5VrlxBJFLkM+WZCyFEAEIULSGa/uEq2r76VJIyjdoF ekAepuFRz2sNvXRLrPIC0UTuCQgRhAhCBACECEIEIES1KERDWIhmyuIHUWIaC9FEFqL+mhCtOpWU LHo2OM/mz9Niml+795OzPVMFuSf6BIVoPAtROgvRDBYip/sKQhTHQvQSC5EENxFQsXYNla9exUK0 FEKkI5sGNpE/BjWigcVoD5DoQjSdTizLpot8r1euW+v4XCgbPRJCBJLvHRovH2YdsoeF6BRFjWnH WIj2sxANZSEasoq2FZ5KQtZQzwZV8196To9VnsEeqQZvUFZStmlqIPdEQIiKWYj2sBCVsRCdrHS8 rzQh+oCFaAQL0RgWorEsRONYUmJJGoQoDoVIkwZruqcnmRAV96LmdWpblGravXm/bAT+AEIEfCOp v0MUL0I0mIVoBgdY0SKdhWiCKkQrTwEAgmhCNJiFaBwL0VQWouksRE73FYQIQmTNaOpeB0IUU9Lb 69oXQgSiKkTT0uncYhai/DyqXFFAJFLkM+ULIURx9p4JPFvq1auXCyFKAiGaxsHfVg4CAQBVTIMQ QYiiJkTtKRND5mLWK1SnSS8qCYoRhAhAiACECEJkLUSDC2nripMAgCByT4QrRM+xEL3PQjSchWg0 C9EYFqKxLCmxBEJkIUQS3ERAxZpiKl9VSMeWLoEQxbUQVbV1dY8bhAh4EaLp0+hE9lK6yPd65do1 js+FslEQIggRhCiqQjSdA6xoMZWFaDwL0duaEBWcBAAEkXviVRaiQSxEY1mIprAQTWMhcrqvOiza RHcNSqdfDZ9Lv5mUQ7+dtoJaTV9JrWYUxpxOPXs92aNHj3oQogQVIm242cOjA/+d+XAd98O/DEPF rI83H8ZnO3TPmLb0wFgKkUWdw66bwzysYHpWZYYQAQgRgBBBiKyFaFAhbck/CQAIIvdEOELUcV7x 57/p/Lcx995771P333//39q2bdu5TZs2DzGdYgHn17Fdu3YPdO7c+d60tLQm/Ey5QYQAQpTAQtSk UXAeTh1XkmOUCyvRKenXyP5j1CZyYZd2nTphCJGnujnPwYIQgVoVonQRokV0KS+XKgvyiUSKfKZ8 4QIIEYQotYRoEAvRNFkNLkpMYSEaByECwFaIBrIQjWEhmsxClM5C5HRfdZxf/Fmrro8NlRVnREza t2//pw4dOtzP/DEWdOrUqTXL0O+6dev2f/zCbMAy8APmGxCieBIilwJQvSCBncwYRKO698ZcTKrT UNIOyVfpAdL1FCnnWG33LEQe6la9PdAjZUzfYagehAhAiACECELkJETpHPxtzjsJAAiSHqYQdZpf fOH+x556i8XkPpGStLS0pvzPO/ift8eIJkxj5mbpHeLnybf79+//NXlhQohYiCS4iYCK4iIqL1xJ x5YsjqEQmQX75iKg9eA4rVanyYWVIFTLh9LjYn9OmEPmPNct9HitXG6G+UGIgCshmpZOJ5YuoYt8 r1euKXZ8LpSNGgEhghBBiJJCiAayEOWeBAAEkXsiHCF6aMHa8+2f6dkzOFztvzkY/zHzI/7362MF 5/dD5ntMXebKVOwdim8h8jpkTu0RsRMQtwsbuDjOJG972QpTiFzXDUIEIEQQIghRSgrRQBaidFkN LkpMZiEay0L0VlCINi0/AQAIognRByxEo1mIJrEQTWUhcrqvHlq49lynf/R6ml9WN3Igfo0E4zJk rX///l+PMV9jGbhchCAVe4dSU4jcpu9GnIJpVeftdE70hcis1wpD5kDcCdEiFqJcFqJ8FqKCAt8p XwAhghDFqG6tWrV6LtWEaOoHhbQx50RSMv/JJvxjbUL/mJic9QPRQe6J8IRo3dnOPXs/Lr1CLCVX 8T19Wbt27b4iL6xYI88UjRR9UaWoEEWjh6hmdbfa6iGyHXJotZgChAjETIjSWIimshBlsRAtZyHK Y4HJ953yBfMhRBCi2NStNl/eqhB9wEI0VVaDixKTWIjGpIAQbZzYj26VH+wf0hHoA09C1JuF6H0W olEsRBNZiKawEDndVyJEXXr2foyD8Oukp0ZkKFWFJP6E6MULJMFNBFQUrabylSvo2OJFcTxkznkO kTb8zcscIvtzoi1ENduaN/Gw/DiECIQjRCw2J5Yspot8r1cWFzk+F8pGDocQpShdu3ZtIaSlpTWE ECWJEG1YdsIDxfTiL2teSLc+WezuvLcernmR/bIfzXOZfg0P0xBP5axiyB/qBHqJXpzg/VyQmkCI IESJJ0TqCm0Oq8wpK8kZJcEyDRerz0VPiIxD+DwCIQIQIgAgRI5C9D4LUfYJD6RTW6OoOJ7DknOz cs7NLEQmx817oonDdy6CYuOlvG9WiditTxR7rCdIVeSegBBBiKIjRO6+ExTesDL7D5eq6Tt9U8jb N47aU/eHozxkzuRjs2r+mR7b2nGYHYAQeRGix1mIprIQZbEQLWchymMhknlEPlM+H0IEUkiI2ooQ lZ7jAIyixsSjl2j0viohmvL+Slq/9LgH0ukvgZdKZ+oRFJhbnyiyP+fNzsHj+lWdy0I01+KYAPel W6TRhHqMP+6tvOODw+bM8gTABLknevefS+8V7aaRpWdowpEvafKJSsf7CkIEIXKeuxNNIbIWF9Pe EcP3gOq46MEK+aBrUCwyH47FKnNuPwoLIQIQIgAgRGEI0ToOAt1TI0SDFdnIsDy+iHrcXCcoM+nV QpRhmmaVXHkrjxNa/lxeX9MFyQqEKAmFqCcLkQQ3EVCxehWVryigY4uywhAiEDZa75DFkDmnOVEA eBKiqVPoxGIWohUsREWrHZ8LZSM0IZrCQpTJQpTDQpTLApPnO+Xz50GIAIQoakL0HgvRkuMAgCBy T0CIIEQQojgTItNeHfeLSQAAIQIgwYTofRaiyRxgRYsJLESjWIjeZCGazMHf2sXHAQBB5J54JShE I1iIxrMQTWIhcrqvIEQQIhANXAyBC3fBBQD8EqIpLESZLEQ5LES5LEQybM5nyudBiECM3qHx8B2i mAvRuyxEi44DAILIPQEhghBBiOILq3lE6BkCECI884HP79C6devuT0UhWpN1DAAQBEKUpEIkwU0E VKwqpPKCfDqWlQkhAiAZhehBFqIpIkSLWIgKqHL1KsfnQtmIjyFEKYp8kFVo2rTpQAhRlIToPRai SRxgRYvxLEQjg0I0iYO/Yg4CAQBVTAoK0bssRMNZiMaxEE1kIXK6ryBEECIAAIQIQpQy75lAL7VI EYQowYWo/4w11LvreACAgVc+yqR3i0sgRBAiCBEAECJnIZo8mc4tXEiXli2jyuXLiUSKfKZ87lwI EYQIQuS3EI3a/ykN3LCf+ixaTT2mLqSnx86kv4+aRn8fmQ5AasK/f7kP5H6Q++L9dXtpxN5zNL7s 3xAiCBGECAAIEYQIQIhiKUTvshBNlOWxo8T4Y/+hUQc/o8Fbj9CbBVuo14IC6jkrm/4xYzG9OH0R ACmJ/P7lPpD74c38zTR4y2Eauf9TGnf0Ek1gIXK6ryBEECIAAIQIQgQhghAliBBNOF5BY49cpI9L z9CgTYeof+GOgBi9kbeJ3sjdCEDKIvfBO6t20sCNB+njktM05nB54H6BECWBEElwEwEVhSupPD+P jmUuhBABkLRCNJlOLMqiiwX5VLmq0PG5UDZ8GIQIQgQhiqYQTRBxiRLjObgbK8PmPvmChu89R0N3 n6IhO44BC/766jv09PjZ9N6GAzR4+9Go5vXEyKn0+Iip1GfpmkBe0cyvb/Za6vjmIPrn7GVRzyuR +Gj3ycB9IfeH3Cdyv7i5rzpBiCBEAIAUFKLuLESTWIgWsBBlsxDlsMAs953yuRkQIggRhCgaUjTu 2H9obNm/acyRizT6cDkwYVjpabrsiq9Vf/Piu9ffENg26tDnvuclAXjD3/2xOq+vf+tqenZCRtTy +tv7I3Tf87j3iRcCecm+VL7mcj/IfSH3x/jjFRAiCBGECAAIkbUQPcZCNImFaAELUTYLUQ4LkfQS +Ux5BoQIQgQhipoUVSOBH9Ahc0f6LCnWScO3/t+1NJqFYcyRL2sCZj/y4rQkze9e/2Ndfr0XraIx hy8GyuJnXhLw//bRp0KESIRAJwOpiHpfuJQhCBGEyB2jqbvcb016UQmC0ISmpF8jfm42ooHFaAsI EYQIQgQhiooQDSg5x4EYgVpk3PFKGlN2ibq+p+9FueWee2lY6Vka9QmLw9H/+JafpDVo29GQr7B/ sPkwjTz4eaAsUiZf6nasgsXnS/p507t0eT06ZBwN3/dpYJ9feaUSEKI4FqJ/shBJcBMBFStXUHle Lh1buCBsIaoKoutQ93QEoAlPcS9qLs/Oh0ejLZJJiCZPohNZmXQxP48qC1c6PhfKPtaEaCIL0XwW oqUsRMtYYHJ8pzxjDoQIQhSbuqWlpTWDEIEaabhIv+7yuE4afvVQdxq05QgN33/BN0kJyNeRf9Pz UzN1ef3gxvr03vr9NLTkjK+SIvIlknXlN7+ly+/F6YtpyI7jNPLQF4H6Q4ogRBAiP4UomwY2kXut PWUiAE0KMh+ug14iCBGECEKUfEJUmy9vCFH8CZGIwY2336mThvZ936V31+2jj/ecC0iML0IUlK+2 L7+hy+uXv2pJ/Vftog93ngjs902+WOTeyN+qy+tr37iK+uVtDsjeiAOfBaQJQgQhghD5KEToUfC3 ZyYehh2mtw88P5v3y8Z1SXUhmshCNJ+FaCkL0TIWIhk25zPlcyBEIMWE6B0WonESvIJaYwwLgfQC GXtRnhg1nQas3UvDWIhGsxCNZWmINK+xLEQjDn5O//vXh3V5tXz0aXpz5Q4awkI0ioXIl7w4jVGH v6S0YZN0ef3w5zdT35wNgSF6w1mIpP5+5JdKQIggRBgul2ISEk9yBiBEAECIgO9CVHaJ+q/erZOG K75xFfVeXEzvrt9PH+/7NHCMH9Kgydd19X8Z0hv1tvQQ7T4VkBi/5GvkJ+X0xxde0eXVpHVbej13 Ew3cWhaQMzkOvwMIUVIJkQQ3EVCxooDKc5fTsQXzwxAibbgchldFSnyJJYZBJpcQPUBbJ02kE5kL 6WJeLlWuXOH4XCj7eGhQiCawEM1jIVrCQpTNArPMd8rnzIYQAQgRiB3VvShD9b0oP/j5L6hP9jp6 f+MhX3tRRKyG7T1PX738Cl1+PWYsoXeKS2lo6Vnfe6NkcQg1r989/gK9sWIbDZY5RLJgBIQIQgQh 8lGIgqvLWQXOwZ6Gql4PLcjWsA62q+aw1CCSYCoMavpar4ZJz0ZY6dmWV6t3ELvhgsGeH6t6a+Uw I0SOHNJy3SbGdEx6grQ2Q88fhAhCBCBEPgvRYwWl9MKaQ6CWeL7oAD2zspSadXtG9zL873vuo85T FtNjWesC++W4iPMrPkjPrdpH7UfM0s/p+dbV1HHcfHp03ip6Km8HPbd6X+DYSPN6vmg/PZ23k+oa lvf+Xe/36G8zc+nJZVvo2cK9keeVgvxpblE5hAhCFNbQqmDg3b2fEpjbBuIG0QjB0BOlpf+wIcCv FpQw07MqL6drJTChQ92MQmUuMkZZMy+bu7TctImlgBmuhXYc5hGluBBNYCGax0K0hIUom4VIhs35 TPlsCBFIESHil/d3uvTp//c2b3w4/o99Bk77Y+/3Zv+h97tzQGy575UBGfe+9Pb8//eznx9TX4Q/ aXZ36d2P/2PZb1/sm/n7l9+eJ8dFnFfvARmS1i2tH9ig5vXt6+udvqv7s8t/8+wri6QskpccG2le 9/UaMPc3T7+8OCRI6fJEwa+femnJ7/7Zb8F9vfrPjTSvVELu0/v7fDDzT/0GT0578plf8X38QwgR hMi0x8Kih0QffCuBe3XPhV5IquVAF5wrMmDX82PTy+E2Pefyhp5XfY6hDWrKpgpLTd460XAQSy9p 2beJWY9eVToh4uNwbUEqCdFcFqLFLERLWWCyfQdCBFJFiC7jl3dd/ufPunXr1rxTp06/b9++/Z+Z vzBtQezgQLZdmzZtOl111VVHVWm4/fbbP7r33nuf5n1d+JD2zAM+5PVA27ZtO/z0pz9dquZ1ww03 rGjZsuULrVu3foSPedCvvKTcv/rVr15T85J6cl49Oa/Hpd5cnr/6kV+q0KFDhzbMH7t06fJrvn9v kRcV38tXQojiSYh6XCAJbiKgoiCfypfn0LH583wWImvxMJ17VD2My2QYmGk+dumHk56VQBl6mox1 NUvLJm/Tnhe7BRU8peXQJl4WS4AQJZcQTZxAJxYuoIu5y6lyRYHjc6FsmAjRoxAikFzv0AYNGqTX 5su7f//+V8lwG/6xN5BvInXu3Pnurl27tgCxhQPb34gUGXtRWrVq9azIC//vD3xMSwmAfcjr13yd 7/3+97+v6yFq1KjRKBEvkWLe/1sf8/otpz1azUvyZhnqLhLE+3/H3ONHfqlCt27dfsX8L9+zjXv0 6PHTPn36fFt7UUGIIER2vSN6iTBbcCFUiDQZMZMC8+Fbdun7nF51D5E7wbHKu6YHSp+H3YIK3tKy bxP9EEKHBRMgRBAiCFFKosUA/O5vmHTv0Lp16+6vrczlRx0cNldXpEgCK/7R/5y31Qcx5SZu91/e f//9f1Ol4eqrrz4owiA/ft7fiG+Am+XYSPOTdCSQvvzyyy8Y5KtHp06dWvG+20WQ/ciL0/kFp/c/ 9evXz1DzuuWWW6ZIDwcH9XfKg1aOw+/Ac9veyP+8ge/da2S4nATjkCEIkaug2fb7RMahW/ar1ZlO 8LdNP4L0THpP7ObThKblNG/JmI5dWT2m5eqbUC4Xt4AQQYgCQjSezs3NoEuLF1Hl0iVEIkU+Uz57 FoQovt4zyfth1toUInmByxAb+YEHe4rqyl+aZV4RiCnXMD+4++6731BfpvyDzwn+JeBmEdbgcX7k 9z2RHjWvyy677DPpyRHxYjGuJw8+WXAj0rw4jf/HaV1/zTXX7NR976hly5e4DE15339L3f3IK9UI 3qvfkqFyMvwVvUMQItdBs5thYNXyYbdanUWvh+13e/xNz3rFNZPlqYstFmSwHKpmU1avaXn6lpHL IYcQIggRhAhCBCHy7yUuP255kUtQxf+8HMQWltGvcRB19a233jrRMH9omAhKUIa+JcdFmpcmv8be qGuvvXazDJnUhl8Fg+wrfMjr6yI7X/nKVy6q+ckQwGCvkMx9+UakeaUqcs/KHzUgQ3EoRC+yEElw EwEV+XlUnrOMjs1jIerg3ypzzhKh7LMZkmY1r8f2uz2+pueiB0dNy+tHTe2O95iW928ZWcsYVplL MiGawEK0YD5dXJ5DlQX5js+FsmEfUUEahAhCBCGKyosc1B7aXK5rrrlmmyoN99577zMiDcEhUV/T JsxHgqQhsmPsjbr55ptnyZhU42plkRAU7ctlXpqa1ze+8Y1jwd6hn4gIqr0bIHzwsoAQAQAgRBAi CBGECCQkWhBl7EUJDmG7MbgS4GV+BL3yIBPhufHGGxeped11111vyzwmGU4nDzw/8tKWdm/duvWj al4/+tGPVsocJhlKJ71DWBkNQIggRABAiDwK0fhxdC5jDl1alEWVSxYTiRT5TPmsmRAiCBGECPiP LG3eokWLviIE2l/2RXaMc3qkF6Vbt253yHweCbDCmTAv50peweFx/58mX9Ib9e1vf3uPmp8cIwtq yNwU6dXxmpf0YLVq1er5e+65518iXFoPkfRG3XHHHUPUvBo2bDhBHq4yd0j24+EKIEQQIgAgRBAi ACHChU4B5NsxqvBID4m2qIWbXhQveYnYqN80km/9SBrBeSfXqnl95Stf+VKGtcn8IW0ImxchkmPr 168/VxUeCQyDweE35MZV82Np6iULRQQXXLgCvUMgaYWogAOYCKjIYyFaBiECIOmFaD4LUQ4LUX6+ 43OhbCiECEIEIQIJijxA7r777n6qGDRr1uw96VmRHhVjL8qtt946Xj64ycHV9732osixMtROTe+7 3/3ubklHkKW11X3SW8SC0kSWcJbeIy+9UVoQePXVVx9Q05T5SNpiEV//+tdPqPvkw6Kyupws3hBO bxQAiSNEEtyET0VeLgtRNgvRXCp8pCst/8O9AIAkIr9rZ9o2YTwL0TwWomUsRHmOz4WyoR9WCdG4 sXRuzmy6lJVJlYsXEYkU+Uz5zBkQIggRhAj4FyhJr4txZbdvfetbh4LfgLrarBdFFlSQXhQZOvfj H/84T5aubtu2bUenFcWCQdkPjHOS5GOeslpdq1at/qFu/9nPfrZYW1BBkB6eK6644mzjxo2HO+UV nJP0tZ/85CfLdN/faN58gNRL6qBul28fqQsq3HvvvU9JT5aUQfKGHAEIkV6IJEiSYEmCppxBA2nO G29Qep9XacqrvQEACcq0vn0o4803KHfwYNo5eRKdkmW3IUQAQoSLnOy9QyINMvzNKCnSWyILGRh7 UeSDrDKnR5bCZjk5pw61k4DLaiECTb5ENurXrz/fsIz3UMnrlltumWTY/pH0RsmcoxtuuKFA3dep U6fWdnnJPulVYsl6Tj3vm9/85ify8BSBMyzvvYnrdJv0Rsn8JnWf9JLh46IAQlSDBEdfcpB0JnMh 7UlPp6LhH1P2Bx9Q5oB3aEH/twEACUrWgAG0bOAHtGbkCNo7LZ3OstT8W+YQQYhAqgoRLnDKCNHX pddGnWsjsJxMFUEw6UVpJnOIpBfJpFdJFlm43OyhpC11Ld/+ue+++55Uz2XpOinSw1Ky0bi8t8zp 4f9NM35gsEuXLi3lAWgmRUoA+C0+pr7MRTLK3l133fWO2fLexjlTwp133tlfhvRh1TmQNEIk8wEi oDIvjy4tX04XFi+moxkZVDJlCm0eO5bWjxpFa0eOBAAkKHIPy71cOnUqHZs7lz5bsoT+k5sbuOed ngtlHwWFaOwYOjd7Fl3KXEiVi7KIRIp8pnzGdAhRHCF/SBbatGnTFUIEElqIWFKeMMjPp7zt78aP pHbr1u0uo7gEh9L9U/uYqVlviipE8gATuVLP55uoi8ny3r+TXiJjXtJbFBxG902zhRZUIRLR+ulP f7rEID/T//u//zvTsLz3O23btu1sLIPImoihzCvCAxdAiGqEqIKDpC+XLQtI0akFCwJiVDZnDh2e PRsAkKAcYeRePs33tNzb/87JCdzrbp4LECKQlO9QNEJqCJE8RGQ+kPTEXHnlladVGfje9763Rf3v X/ziF7NlzpBRUKQHJzjX58dWq8EpQ+bk20U/u+mmm+bY5SVD8IwfaRW+853vlLCUNZc0rJbiVofM yXBAo9hxPU9985vfPGIQuldEAo2r3N1///3dZL6RPHDVD8Pi9wMSV4heYCGSv/ZGRmVeLgdKy+nS 8hy6uCybvli6BACQJHzJ97Tc23KPy73u5pkAIQIQIpDIQlQtKWZD01SuuOKKM8Zt119/fWHnzp3v kdXggt8mslweW5MUPuZHrVu37u6Ul3GomyxyIMt0ixDJPCbpbbJaHlv71pDMTeJjGxllz4jZ/hYt WvThvP6Pz28gq+pBiACEKFSKNDECACQP2r3tVoYgRABCBBI6UFJ7Uu6///6H7aTBiKwu16FDh/tl lbjgB02vk7SspEFbxEEkxaxHyg6RI+np6dKly2/cyJc2RM+qR8oJWclOlgE3ypfT6nYApJIQAQCA XogeodIxo+ncrJl0aeECqszKJBIp8pny6dMgRABCBPztJdIkRYaGXX311QfdCIMMaZPemqCg3K4O YbN6KKnD5uRjq7KMtltBadGiRe+goNzJadwk5bXrsdFkT+Y0iezJHCW3ecn8Ipm/JB+FDX5z6brg ghFYaQ4khxDJBGkAAPARCBGAEIGEDpaUYXM/adSo0WgnYbjssss+a9269eMsDL+Vb/dID4qToGgo w+au439/0I2g3H777cNEUGRBh+DwtR9qgmLXY2PskZIhd055/eAHP1jP4vX7rl27tpChdsF5UXXR OwQgRAAAACECECKQpAQlRVab+yHLwH12wvBf//Vf/5aPswYFReut+X5w2N1lTg8kTVJkIQc3PVI/ //nPF0iZpLcm+OC7QYbKaT1RTh9n1YbNSY8Uy94ou7zq1q27r3379n8Jzom6Tc6RoXJYchtAiAAA wIUQdWchGj2Kzs2cQZcWzKfKzIVEIkU+Uz4tHUIEYvMOxYdZUwdttTkOmK4Rwbnmmmu2WUnDHXfc 8aH0oAQXG/iluvy1mx4U9QOtIhzyUVarvK677rriDh06/FF6a7RV7NTlr93kpcjedSw7f7bKSz5A Kws9SK8X1+0OrtuN0h6QIZCcQpRLAADgJ2UfDYEQpShJ/R0iCFFqBUxBSQl8t0c+RGomDbIwAQvK H5TemuvlHDe9NcYeKZnbE+yR+r1ZXrK8Nh/3QHCO0m0ynE/mKEnvkhdBUZcWlx6p733ve9vNer1a tmz5gvR6yYdn1SGAmDcEklKI5LsiPlO5fDkAIEkI5xlQ9iGEKIXfM4F4ql69erkQIpDQBCVFlqn+ gQwZMy55/aMf/Wil9NawoPxaemuCQ9fCmlujzO0J9Eh9//vf32DsrZG/MgTnKGkLNoTVW6MsLS4r 0v2kWbNmHxiF6O677+4X7PW6U6RJGwLoNEcJgFQXIgmczkwYT3vfeJ32AACShtN8X1d4FKNqIRrF QjRjOl2aP48qFy4gEinymfL0qRAiCBGECPiPNt9G5sxID8l1111XpCyvvc2qtyYcYbDrkZIFG2R5 bbW3Rnp3wv0GkGHYXED2VBlq0qTJCJmjZFywwe0QQABSVYhEhv6Tk0OFDz1IJYPfob2jBgMAkgC5 nws7PUhfZmd7kiIIEYQIQgSSKmiS3p977rnn5eDy2sfbtm3bgWWoZaS9NcYeKU1SWEb+V3qkhF/9 6levsbTcqy3YIA86GV4XydA1ZdicfEuoviZ79evXny9DALXvKIU7BBCAxBKi51mIJMgJn0r5gj1z cekSDpza0+c7iqjiRAkAIAmQ+3kl39fnWTy+zF4auNfdPBfKPhwMIYIQQYiAfUCSCEjQFJSU70tP kHw4VRm61kxkQhMUtQclHIJCFBg2J71AN9xwQ8Gdd975vrK89i+V7/9cLseHm5+cqyzkUE8m/skQ QG15ba5bY9kuCzZoc5QiqRuIHDw3oihEPViI5K++EVCZk0OXsrPp04ULaWVHCBEAySZEKzr8lcpm zqQLmZmBe93Nc6FsCIQIQgQhAhY9E2/8fXxp767jKRF4pcs4evnh0fSPjkPpqbbv0sO/60ld7+tF j7R+lZ5s05+ebz+YenYaTr0eHhM4NrL8xgXSkfSebfcBPcR5/e2+V+hvf3iFHvvTG/TcXwfSPzt9 rOQ1LqK8Xukylv7VeSS90H4Ipd3/OnX5/b8Cdet+/2v09APv0osdhgb2y3GR5QUiod9zo/K0uVt4 hsS3EH25dCmdmjuXVnT8K4QIgCQTovwO7WjP5Ml0Zt48+jff63LPuxOibixEI+nc9Gl0ad5cqlww n0ikyGfKp4oQ3Q8hghBBiBJBhqRXQoK8c8e/TAjOHrtIp8u+oLL9Z2j31kO0btU2Wp2/gdav3h74 78N7T9HJw5/RmaPlgWMjzU/yOnboPO3deYQ2rdlFRQUbac3KLbRj4z46VHqCThy+4Fteko6kd7Dk OG3bsIeKV26mohWbaPPa3bRvVxkdO3guUB4/8gLhcWjXGXrt8QmnpZfSzTetQO0JUQUHRxeXLKET c+ZQQQcIEQBJJ0QPPkA7xo0L/NHjSwgRgBDhIodLMAD5hgjRWZGNBOE0i8NxFodDe04GJGjHpv1U uuMwHd53OrBd9p9hafAjL0nnBAuWpC15SF6S50GWoWOffOp7XqdYeI6y+OxlAdq5+QDt2nKQ9u0+ Gth28sjnvuUFwuOgCNFj48/IMEoseR5tIZLgJnwqcpZR+eJFdHzObBaidhAiAJJQiLaNHUMnM+bQ xSWLWYiWOT4XIEQQIggRMAtAZMW2bweESALtBEF6Uk6xHEjPjfQIfcJiJD1GJz65EOhB0Xps/ELS PM7yI3lIr9ARliPJW8oQjbykHkcPnA3UTZC8pNcrGnUD3ji48zT1fWz8WZnPFVzS/TIIUZSESP7a GwEVy1iIFi2iY7NmQYgASEIhymMh2jp6NJ2YPZsuLmYh4nve6bkQEKJHWYhGjqBz01iI5mZQ5fx5 RCJFPlM+dQqECEIUm7q1atXqOVzk8IfLyeR8WS460YRIlSIRBREI+fdoCYOkKWlLHpJXNOXELi/I UJwIUdq4c7K6oKwIKH9UgBBBiAAAECIIEYSo1uqGCxyZEMmy1HKTihCdOXox4ThdVh5CMuRlll8i Xp9k5MCO09QnbZy84BrIHxPwgoumEElwEz4Vy7JZiLJYiGZCiABIeiFaxEKU7fhcKBsyCEKUosiK vcFVextCiECIEMny1YkqRADUlhDxi+0WCBGECACQoEI0YjgLUTpdyphDlfPmEokU+Uz5lMkQIgAh SjghKrsIAHDgwHYIUcyESIa/REBFNgtRFgvRTAgRAEkvRItYiORbRA7PhbLBECIAIQI2QnS67CIA wIH9EKIYCpEEN+FTkb2UhSiThWgGhAiApBWiUSxEs1iIsliIljo+F6qE6G8QIgAhAhZCdKQcAODA /m2nIEQQIgAAhAhCBCBEECIAIEQQIghRLCjp14i01ZGa98t23A7QphAiF0I0/GM6lz6VLs2ZTZVz M4hEinymfPIkCBGAECWaEJ06XA4AcGDfVghRzIRI5gNEQMVSFqJMFqIZkQpRNg1sUqc6UBa6p9d+ 8J75sFKmh0f7n3dxL2peR19vI4kqDbXWpsB/IRrFQjSLhSiLhYjveafnQkCIHoEQgSR7h+I7RBAi M9b0bVb9Uru97zbH7QBAiOJNiJ5jIZLgJnwqli5hIVrIQjQ9MiEyE4MYBsu11puRgkKEHqJEFKKR LEQzWYgyWYiWOD4XygYPhBCB5HuH1q1bdz8awh8hOvlJuXtWvEu3G1+OnebanzPxEcPLtBm9saLc W74uKTaIj7Z9WicP5Y2IbfTGbWYBxCM0LWp5JhkhvzGLtlN+Vw9PjH65IESpJ0Q1QXIjal7dU9Se Mms5eI86qhA16UUlKTBkDqSQEH08jM5NnUKXZs+iyow5RCJFPlM+aSKEKI6QD7IKTZs2HQghAv4I UYjcOAmOuSBEK4C1EiKr7dHK25zoiaCjWNz2LhUnihCZ/MZMrxmECEIUVSFShsuxFGQqgXSshs1B iCBEAEIEfHnPBO55kSIIEbAUohOHvnDPhG41geptzahJ8N+b9N3qeHyT22qE4eEJX3jL1yWqlFiW Kcr5mtYv0A7NqF/BFzEr04mCAdXXp85tA6j4UAzzjgT1N1ZNN0q3OS5avyeVvVtOQohiIUQvsBBJ cBMBFUsWU/nCBXRs+rTwhUiRgkDg7EISSuykKb29bSCum8MSPCbs4V0WQ95cC4BHIaopT7D3TKmr YxrGY32skx9tGn7dRlN3uz+QqefV8tDMhBWikSPoxMwZdDFzIVXyPe/0XCgb9AGECEIEIQJREKJO A6jfbTYBK5PeqSYgT++bpEKkikeMgvNUEaKHO3Wzvp4QIghRFIWoJphuRAOLjQssaNv8EKLQhRuc 5uzYCZFRAmwDcd+FSB1aaMQ41NC+3mr7ea+Tf20aVt1MJM+qzGq+dSBFsRGiYUPp3JTJdGnWTKqc M5tIpMhnyidOgBBBiCBEiSZExw9+4Z7xihB1nEtFfWoEpPN44/FzqbMWzPbZ6nCsIW0lkC+yKEt6 R/2xxjzkv7VjrbYby6mD6+emTdS03Z7jNd+aPFg8TdsquN2ibYztZCx3yPVQ0te1V/X2ZtQvX5+P XRpurqd53gOUNtLXUT3O9PfkM3s2Q4hSR4iUv+4rwbYamJv1TIQjRLqA2CIv10KkC8TVIF0vCI49 RU6LKhgCdWNQX5O+Pl+1TazqrbV99bFh1MnPNvVeN3W7Ul5jj6PN76y6rBAiCBGAEEGIEkOIjucr vRCGQL4m4K4Knu0CcLsAPiQQPrhV6ZlyDvzthEgnM67yNqIvS6hsuZAoF/mqQtS5o/UcJWnnWAlR E8M1UNPwdj3t87aUWQhR8gqRBDcRULF4EZUvmE/HpqWHJ0RWvTlqcG7Sc+JdiOx7nawEzDx4d+jB 0kmOw8IQEQiRUbbCKqup9Litk59tGk7dFMnRtZNSrurt1kIEXAjRiOF0YsZ0urhwAVXyPe/0XCgb CCGCEEGIgI0QHTvwhXvG6YXo2IGt9HrjmkB3avWxyvbGA6iItxW9qgTg42rSVLc3eXWrTV6hx2tp y/apxh4jJS2rPKq2N6PX8/X1VNNSyxqKvpfH/tgvws5XV2dde6jtr2+nY6qsKu1klmZIuZW2t7wm BrQ0vF5Pu99Y1flzdb1EU02Oc9vukVC6CUKUKkIUOlzObF5IaLDtXYjU9EIlxVuQbp+WU9n9GTJn 0vukSqSZCNjKWTh18rNNw6mbRQ+RhWSHDgd0uDYgciEaykI0eRJdmjmDKmfPIhIp8pnyCeMhRBAi CFFqCZFFYK0E41pQbB6AWwmV1T51m71QuBEie2Fxc3x4QuQ1XysJDBEftQ1jIEShbeP1eroRIudt ECIIkX9CZP9Xe7thc56FyEE8PAXpjhLjtlcmBkLkNv1w6uRnm4YlRE5ziIxtbzXfCWIEIQIQIghR bIVo/+fuUQPiDhlV2/IMgTdvm9pBkZa8qnP1AbiWZob5PBqTYVZTQ47XttWgF4otjtvdlCH0eOtz a+rlBvf5ui9/TXubXRertgopt05Atthffw91qmNz7ezz3qKXKcNx3to9PEo3noAQpYIQuZkQbxFw J04PkYchc9EWIt96iLT9td1DZLMIhENbhi6wELtvXkGIIEQQIghRygvRUQ72XGMIiKu2b6HXlF6b 1/Iy6CElEF8VPHeVEoA/NC6YXp5+hTa7AHqK8Xgl7aMmeUgw7WW7nZhYt4lad6djPw87X6vym7e/ Sds6tFX19TC5zrr8TK+/gtfr6fAbs8o7sF3575DyR4ESCFGMhOjZCyTBTQRULMqi8vnz6Fj6VM9C 5Liimc1qaG5XfzOXGPueA1/nEDlJTkyHzPk0h6i6nH62aWSyF+73qqyHbAKdEA3/mE5Mn0YXF8yn Sr7nnZ4LZQPfhxBBiJJPiNLS0prhIvskRPs+d89YQ0Ac3L6qtxKwN1b+vfcW02MeGhtML9cQtDuW QZEtCaoN+3XlsMi7ZruaFotErnM6ZkzpUMe0TdzVwV2+9uWxSM+hbU2vh8l11uVncf2r8Xw97X9j +rqq4sfXXjkupPxRoGQDC1F3CFFyC5G7XhSdNFkOlao53251M90+P1dE04lMBKvMRUWIrOutlVWT iXDqFK029d775bBEd/BYvTh5GNoIIQpTiD6ic5Mm0qUZ06ly1kwikSKfKR8/DkIUR4gICU2bNh2Y dO9QXOD4EiJdIOwi2K8JYK3lwKtM6ANmF0KhltkQ3HsRIl2buKlDGPmq20NEJFc/h2jKPu9CZKyj KnmehMjz9fQiRPo6qeINIQpPRAQIkYs5IbbD6qyXgtYPl2pksuyyUcLcnWMdpLv4/o6bpZwdg3p9 OmHNs3H4cKn5MtZu6+Rfm/o6ZM5YP4d2dv0hXQgRhAik7h8V0Qj+CVHZ3s/dM0YfENfs08tI6P7P qVAVojE12yerPSwcuBfq8qwKsCUwdjpet91wTqEh+FfT1kRispbncr3cqelYoc+bRWC5Wbtp273n q5Zf37ahEmhsu5B8zK6lst+uHa2vf/jX0+43ZnacsXzG31O02L0+OYRIBKRp06aDtLa7+eabp7Vt 27ZjbclRiBA9z0IkwU0EVGRlUvm8uXRsqjchUgNZ++FO+oDb+i/86v6ac0IDXW/n2AbplvOgPPQ2 xESIrOXBnzr506YRDQe0+16TbY8SeoYchag9C9HHLETT0uni/HlUyfe803Oh7IP3IEQAQgSiLUSh QbsxSLUSIn3gbjGfxjLQN9C4WU0PgqMQmQfX9nlbYSKEZj1my8PLN0SILOblTHYhDzXp2pTZoh3d CJH36+lNiIziCCHyJh9c7p+ZXZNvfOMbx5o0aTKCX+C/jKUcxZMQARApNdIT4TwuECUh6kqlH31I 5yZOoEvTp1HlzBlEIkU+Uz4OQgQgRIknRHs+c48aED84R78v5x3d0K3JhnMLX7lDCWBD01b313AH vZZjVpbQYL4qzTnVwXiTV7aYpq1uN89Xym6ejiO6NjCm+VnY+YaUf4zhe0DGa+HYTuG1o+31j+h6 mv/GrNpen7aLNH1g97rjCS1EIh5SXi73DVdcccU5O2H97ne/u+u+++57kp8RP4y2HEGIQDJhvSy7 x3lcAEIEAIQotkJ0pPQzEOcU9qoRgNt6bUGb1AK7kkCIRDz69+9/VZcuXVpec801O92sonbzzTdP j+aQulAheuYCSXATARWZC6l8bgYL0RQIEYgtbpZtR++QT0I0jE6kT6WL8+ZSJd/zTs+FsvchRABC BCBEECKQ8kLEZb6M7/tvMT/mF3WjNm3aPMTCM+vKK6887RTERWtIHYQIJB/WizqEuxQ38EmIurEQ fTiEzk0YT5empVPljOlEIkU+Uz5uLIQIQIic6NPrjUZ9er7x697/euueWuEfr7fs1eON3/d4qvcD r3QZS0VL9oI4Z16PP9OPv39TgJY9VqJNFA5sO0uHd1+gIyWfRZVda5NKiH6Ulpb2P507d767U6dO rfif9951111v16tXb7mbXiNlSN0PIEQAAAgRhAjU0ru9QYMG6YlY8L59+/6wT7cJlz58JeNs7TLn 3JBec85/+PI8GvF6FohzPn5lBr37YnqAD15ZiDYJ8u7zM2nemCI6sPMcHdr1KR1mcYkWO5NAiIJD 5r7O8vG9bt26NW/dunX3xo0bD//pT3+65Nprr93s5YOk0mPEUnV7u3btvhJJjxGECAAAIQLRpGvX ri0Efmc1TDohqlu37v5EHKrWq1efn7/11NQL545/SQCAyFg0eR1NH5pPpZuO04HtZ+gTkaLdF6LC zjUiRGMTSohENris3+7SpcuvW7Vq9bwMebvhhhvyv/rVr5Z7kR8j3/ve97ZLO0hvU6TtECJEz7EQ SXATARULF1B5xhw6NmUyhAiAZBWiYUPpxNQpdHFuBlXyPe/0XCh7/10IUar2ogTfXfJxVghR3AxX 6XOLCNFZDuYAAJGRxUI08YOltLX4IO3ZfIIO7TwfNSmKZyGS54vMCxTxue+++56Q7wz9+Mc/zrvi iivORiI+ZvzkJz9ZlpaW1pRf9DdKTxPzDREaCBEAIP6FqAuVDhlM58aPo0vpU6ly+jQikSKfKR87 BkIEIYIQWb30+/fv/7VePXrd9tZTUy6cPXaRAACRIUI0qv8CKs7dSTvXH6X928+yFH3KUnTBd3YW 174QyXNEEPG5//77//arX/3qNRGfq6666qhfwvNf//Vf/7baJ0OVZc6RDLfjF/0vZA6RrFonf+wJ d9gchAgAACECEKIUESK5EWTsfo9nejYTITrDwRwAIDJEiD5+Yw6tXLqFtq85TPu3nUkaIRJREPFo 27ZtBxGfn/3sZ4uvvvrqA36Jz1e+8pUvr7322o3169ef36hRozEtW7bs2apVq3/ws3WfmSQ1bdp0 YIcOHf7IMvabtLS0JvKBV5aYa6RnKpJ5RKZCJMFNBFQsmE/lc2bTscmTIEQAJKsQDf2ITkyZTBcz 5lAl3/NOz4Wy9yBEECIIUa0jAYMMLenZo1fzgBAd5YAOABARWZPW0dDXZ1HB4k20rfgT2rflNB3a wUK084Lv7CyKjhCJEMgS2CwbbUR8WFDmyipufg5z+/73v7/hxhtvXNSwYcMJLD09WLI68/9+J6vL derU6ffMfbL9iiuuOGM8V4bdyT5Fhm7nuv+3vOQj7R2CEAEAYipEf2MhGjyIzo0bS5emTqHKaelE IkU+Uz5mNIQIQgQhshOiHs/0vDMgRGUc0AEAIkKE6KPXZlLeoo20lYVoLwvRQRaiQywwfrMjQiEK is8vREBEfG6++eZp11577SY/xec73/lOCT/wc0R87rnnnn/df//93TTx0eQn+E9Zavu38oFWkZy7 7777DekxMqYnz1lJg2XoD8EVem4L9gx9T2SIRebySF/yECIAAIQIQIhSVIhOczAHAIiMTBGivixE WRtoa9Eh2rv5FB3cfj7QS+Q3O1YfcyVEwQVUfiLzfER8br311vEyz8dP8ZGhczfccMMKEZ8WLVq8 2rp168eN4hOUn9+J/Ij48L/fI1LTrVu3/5OheMwdMvSN0xhnlsd1111X3LZt279K75F8r0iWK5V6 yTA5Gf4rPUNS/0g/0moqRBLcREDF/HlUPnsWHZs0kQoehBAlP8EPoTbpRSVojxQRora09aMP6cTk SXRxzmyq5Hve6blQ9t4ACBGECEIUd0J0pJwAAJGROXFtXAiRLJgi3/MR8Yl0SWsVWSxBxETER3px 7r333mfMenxsxOfOoPg0lg+x8sv5l1zum2SFOJEbTrOfWb4333zzrA4dOtwv6fL5/yt1Zm7gZ9h3 ZM6QCEykIgQhqg2yaWATucaNaGBx8tSrpF+jwO+2ezquMYTIhRANGkjnxo6hS1MmU2X6VCKRIp8p Hz0KQgQhghC5EaJTHMwBACJDhOhDFqLczA20ZfUh2rPpFB3Ydp6l6FPf2b7KXIgkoJf7O5Ilrq+8 8srTssCB9CY1b958gMzZCQ5rq57j4yQ+shS2DGmTnhx+CTfQxKdHjx71+NnzI1kRToa6cdm/GxSb 7/zgBz9YZ1xo4a677npHhshJHpxWM+ZmTut6Pr6uiF+kH2KNfyHSpMGaxA28LYSouBc1r1PbolTT 7s37ZYdxXnvKhCxAiCBEINWESJZ/TWghOswBHQAgIuJBiAT59+uuu26Nk/hcfvnlF0R8br755pmy altQfFqrw9zUoW5B+fmNDL+TYWtW4hNc5OAnQfH5oSY+8lFW+XiqzPeRYW4iNFJW+adsk14tVcq4 PM9JWSS/4OIJ9YMiFfgAq98yFJ9CFBx+BSGKHentde3rSYi0sj88GrIAIYIQgdQTokQrsCpEb7IQ nfyknAAAkbFwQlCIFm6gzasOUenGU7R/63mWok99Z1uhuRBJMC9yIcPaTJa0nnf77bcPFfFp3779 X0zER9fro4jP/wZ7Z26XFegkT1mQwUF8rpZyyJA2ER5Z8EDm+Uj55PkjKAJ3WWDVS5ade+65p9f/ /d//vcn72we/MfQrGWIXHFZ3rbp4gt8yZC5ET18gCW4ioGLeXCqfNZOOTZwQgRAlY49DvA2ZU3rj ZP5PUIy8CBGGy6WwEH04hE5MmkgXZ8+iSr7nnZ4LZe++AyFKUVq0aNFXaNOmTVcIEYQIAAiRz0Ik 93VQLq6WZbNbt27dXf4pK7gZFjcIGe4m4sHcZRQfGaLG//7zHj16/DQ4b+c6eaHKYgaq+Gg9Plbi o33EVUUVkKA8/VDyFAELDr8TEfsfbfEEeWb5tXgChAhCZNXW1TLjWYjs6hPcZ1xowdAbVQOG3KWG ED1MpQNZiMaMpkuTJ1Hl1ClEIkU+Uz5qJIQIQIjcCNGJQ19QslDct1n1S6VJ362O2wHwi4AQ9ZlB yxeup02FB6lkw0nat+VcQIr8ZmvhUVshkrk60rMiPTzBYW468VFWdpPel1uDc3PqyzLWqvhI2sE5 PnVFEoI9OVdKfiI/bsXHTkDkXBEqyUt6gkSCgkPwfhHsffJ98YSkFSLDkK3Mh+u4H/5lEpybH28+ jM+2V8SYdkAMrATCos5h181hHpbV8DbPQmR3reyFyNh2Wt28zV8CECIIEYAQxU6ICgZQE+MLpdNc +3MmdDO8hJpRv4LYClF6Jw/ljYit1O82sxdvN0qHNHhH99uJ7zaMByFSelt+IPN5RCxkjo/0+Gji Iz0+we/3/Di4QMH3ncTH2OvjVXzsBCQ41O9yyTfY+/QjKVfw36+OxuIJroXoWRYiCW4ioGJuBpXP nEHHJoyPnRA1aRSch1PHleQY5cJKdLQhYV7kwi7tOnXCECJPdXOeg+WbEFWXz2y5bW9ChOF3CShE Q1iIJrIQzZpJlXzPOz0XygZAiACEKO6E6PjBL8g147uZvFRYcPKtzjEXhM7jPeTpgaI+ihD12eq4 PVp5m2PXTlEgX5HX2wZQ0cEY5h0xc6mzmVTGcZkXjF9LQ1iIchasp40rD9Lu9Sdp7+ZzLEXnfWfL yqP0qskcomAv0RUiEiI6Qbm4ISg+6spudbUFDuzEJ5xen3AkJChzl0tPkZQrKGVSrstiJUPxLUQu BaB6QQI7mTGIRnXvjbmYVKehpB2Sr9IDpAvglXOstnsWIg91q96uExEtfYehel6FSGsDU8HyLkSW 54DkEaKuIkQf0LnRo+jSpIlUOWUykUiRz5SPHAEhAhCiqArRbc2qA25LyVCOb3Jbs1oTomhjlKGQ +gXaAUIUvnRDiNwIkRbQB1dv+3pQLL6pLnAg+0Q0NNlQFziItvxYSYjWU6QN+9OkLFZlSD4hMgv2 zUVA68Fx6onQ5MJKEKrlQxEC+3PCHDLnuW6hx7vqfal1IdLKj/lEECIIEYAQxUSIjh34glwzTglW Ow6g1xvXBKtTTY6f2jG4v/EAmvqqIkTjPOTpgSIljyavbo1KHiHk64cRRqtuEZWL278oHsrk5TcW KLPaU2T+G4sXAkL06gxaNn8dbVhxgHatO0F7Np0NSJHfbF5RZipEao+LNoTObGW32hAft2JUm2Uy FSIJbiKgImMOlc9gIRo/joXogRgNmbMZtqUTBLcLG7g4ziRve9kKU4hc1y22QmQmhJEKUVWayfXh 2uQVosEsRBPo4swZVMn3vNNzoWxAfwgRSD4hkpWZElaI/s5CtP9zco0qRB0ydALSeZzx+IzqYLbJ q1scjjWkrQbyFmWZ2kF/rDEP+W/tWKvtxnLq4Pq5aRM1bbfneM23Jg+WAtO2Cm63aBtjOxnLHXI9 lPR17VW9vRm9nqfPxy4NN9fTuY30dYw3FoxbExdCZCUX8SI+cf0wTzkhcpu+G3EKplWdt9M50Rci c0lJlCFzEKKUEKIP3qdzo0bSJT63cvIkIpEinykfMRxCBGLzDq1bt+7+VBWiY3lKL4QhkK8JuKuC Z7sA3C6ADw2Etyg9U86Bv50Q6WTGVd5G9GUJlS0XEuUiX1WIOnewnqMk7RwrIWpiuAZqGt6uZ5IJ 0TwWogIWorUsRBtZiDad853NBfZCBCBE3oQoGj1ENau71VYPke2QQ6ePp2LIHIAQgSiQ1N8hSnQh Orrvc3LNWL0QHd23hV5Ths1NqT5W2d54AK3ibat61wTgD42tSVPd3qT3Fpu8Qo/X0pbtU4w9Rkpa VnlUbW9Gr+Xq66mmpZY1lAx6qI7bYz8PO19dnXXtoba/vp2O5uqHzK0yLYNFuZW2t7wmBrQ0vF5P e9T2VX9f8cf8oBBlz1tL6wv20861x6l045lAL5HfbCo4AiGKiRA9dYEkuImAijmzWYim07FxY+N4 yJzzHCKnpaDNemPsz4m2ENVsa97Ew/Lj4QqRz6vMVZ/jJG4gPoRo8CA6MWE8XeR7vZLveafnQtk7 b0OIUvc9E7jv69WrlwshSiohsgislWBcC4rNA3ArobLap26zFwo3QmQvLG6OD0+IvOZrJYEh4qO2 YQyEKLRtvF7PJBSiuSxE+SxEa1iINpwJ9BL5zaZ8CBGEyA8hUldoc1hlTllJzigJlmm4WH0uekJk HMLnkVr8DpHreU4AQgQhghBBiPwTorK9n5NrxuiFKLBtuT7wLuRtkzso0rK86txCNQAfo6WpFwq7 YVaTQ47XttVQaBAKp+1uyhB6vPW5NfVyg/t83Ze/pr3NrotVW4WUe0w38/zMrr+HOtWxuXbObeT2 nNph/lgIEYQoWkLk7jtB4Q0rs/9wqZq+0zeFvH3jqD11fzjKQ+ZMPjar5p/psa3te2vshhV6EyLT 1fk8CxpICCF6/z06N3IEXeJzKydNJBIp8pny4RAiCBGEyJ0Q7fmMXKMGxA/OCW5X//J/B72WM6cm iG38DhUGzy185Q4lAA+ml/NO6IderQJo4/FK2mUmeTR5ZYun7ZZiohwfin7Imv2xn4Wdr1X5zdvf pG0d2qr6ephcZ11+ptdfwev1dGSOXoi8/FZjjAjR4N4zaGnGWlqXt592FB+nkvVnWIrO+s6mPAhR agiRvaz4I0TW4mIafBu+B1THRQ9WyAddg2KRGWUh8vZR2EiFyK5Xx16IQjCro8N8IwAhghBBiCBE tS5EhoC9sbN8mAqRSdDuNUD2JkRqWopIOAqInskP1rGXBNs6uMvXvjwW6dW2ELm6nhAiCFEcC9Ez LEQS3ERAxexZVD59Gh0bOyYMIQJho8mGxZA5pzlREeUZhXk/VbKFBRbiVogGDaQT48fRRb7XK/me d3oulPWHEEGIIERxJ0RHSj8j14zWB8TV25e9Q7eF/KXrDuq7rObcwl5KAD5a264P5tXjzbE7fgv1 bVST/229tpjmXb1dLbNaF6vj3bSJmzqEka+63XiOvu270SSz7Y1YTgzlsKvjpAfN29Hy+peGez29 XG+lbnHIvDEiRNNp6RwWotx9tKPoGJWsO02lIkU+syn3MIQIQgTClhP3i0l4Q0vXb3ExzOcCySNE 771L50YMp0t8buXECUQiRT5TPvxjCBGECEIUMyEyyIhTsF8jRPrgOzRwrwqI1aDc6njddjdCZBVs G+TOUYhC8jYRgUC7adu956sTIl3bWkugo0zoRK5mv107OguR9+uZjEK0dvk+2r76GO1ee5ql6Izv bFwOIYIQgUjnX4W94EJYw+YiTDMKZQUQIgAhghApQnS45DNyjRoQt5+j27fSELR3Gv2Z5X79vjnU yeHFJQG0q+Mb3VEtFeo5Kw1CpG2f1N55vos+bytMhNCsxyw7vHyNbWs1L2eSoVxm+dSka1Nmi3a0 u/7hX0+b35iHutY2EKIkFSIJbiKgYtZMKp+WTsfGjIYQ1QJW84ii19sS4ep2IDGFaOAHdGLcWLrI 93ol3/NOz4Wy/m9BiCBEEKJkFaLD2YahWyVuhcgu6K+RCCcBqUqzJhh3I0Tm+UrZzdNxJNts6KBz ezjlG1J+ozRYyolVO4XXju6EKJzrmRxCNOiV6bRkNgtRzj7atuoY7VpzmqXojO9sgBBBiAAACS5E nan03QF0bjgLEZ9bOWE8kUiRz5R/PAxCBCGKTd1atWr1XEIL0e4LBOKblS8rQvTyZrRJHDJvdDGE CEIEIQIAQuRKiJa2+wvlpj1Km597mkr/8QLt7fki7YsCpc8/ByGCEMWmbolWYKMQfbLrAoH4ZoVB iNAm8cfcoBAtnrWG1uTspa2FR2ln8amAFPnN+pxPIEQxEaK/XyAJbiKgYuYMKk+fSsdGQ4gASFoh +uB9OjF2DF3ke72S73mn50LZ22/RlD/ce/Ifv2mxtM99v1/w5h//MLf/n1pnvH1/6zl+0v/Pf5z9 Tpv7p7/Wvt0AFqIG/Gz7Ht4XAEIEIYIQAQgRgBABAGpdiIb/8Q/b7rvvvifbtGnTieOyB9q3b/+X Dh06tPETTvNPnTp1+n23bt3+l98T9fl98V28LwCEyEKIDu28QCC+KfiXIkT/2ow2iUPmjmIh6jWd Fs1cQ8XL9tKWlUdpR9EplqLTvrNuGQvRo2PPQYggRACAxBSiUX+6fyPHYw927tz53q5du7bgf97N 4vJ/PnNXWlpa02Dv0I+Yb/H74jK8LwCECEIEAIQIQIgAALUqROP+8ufiLl26/IZlpZH03jD/zf9+ o59wmj9jfsLPtB/yu+Lb/M8rJQaUZx2e+QBCZBSiHZ8SACAyRIgGshBlzVhDRdl7afOKo7R99SmW otO+szYbQ+ZiIkRPsxBJcBMBFTOmU/nUKSxEoyBEACSrEL3PQjRmNF3ke72S73mn50LZ22/S+HZ/ WZmWltaYn9838DPnmqCw1I0CV/fv3/8q5mvyfMO7AkCILITo4PZPyQsHtp2n9euKA6xbWwRAQrJt 407av/Vc4Pfs9R4wI2NkUIimsxAtZSEqYCFaxUK0+rTvrF0KIYIQAQASWYgm/bVdPj+7bxIZkp4b fvZcLsPZooE817SeIfQOAQiRD0IkwWPu6pk0Kf8xmlP0MgAJy8ilD9Lezadp35azvkiRJkSZ04tp 9dI9tKmgjLatOhnoJfKbNUsPQYggRCCBKOnXiOrUaUQDi9EWEKIqIZr41wfyZJic9OJo83o0YYkW eM6DqL5DE/07RAe2iei4Y8/mM7R4xVhatWc0fUaHAUhYhi95gLYVHaGSDSdZis6Rl/vAjIAQvcxC NI2FaAkLUT4LUeHJQC+R36xZAiGKmRBJcBMBFdOnUfmUyXRs1EgIUSpT3Iuay8I4D49GWySlEL1H J0aPoot8r1fyPe/0XCh7642AEMk8HxnSJs8dCAtI+Hdo3bp196eCEEnQKMHjgtyRVLhnFF2gQwAk LCJExct30/bisoDo79963hchWshCtGrxHtqYV0ZbV55kKTrlO8WLIUQQIpBoZD5cB71EECIIEd4z yfth1kQWojdYiCQQdIMEjdvXHKWM7KEsRCPpUzoIQMIiQrR84XrasGI/7V5/IiD8bu8FM+aMKIIQ QYggRMCa9PaBQKh5v2y0BYQIQgQhghAlrBBtOh0YYjR7yYcsRCM4qNwPQMIiQrR4zipam1dKu9Yd p72bz0YsRB+IEKUXU+GiPbQht4y2rDjJUnTKd4oXQYhiI0RPXiAJbiKgYlo6lU+eRMdGjoAQhc1o 6u6LSGTTwCYcjDTpRSU+5Vc1N6g9ZXoZNueYP0g4IXrvXToxaiRd5Hu9ku95p+dC2ZsQIggRhCi+ hOjJKRf2bTlPbijdeJq2rDpMsxYNoZV7htP5yr0AJCwiRAtmrKDi5SW0Y+0xFv6z5PZeMCMgRP9i IZrKQpTFQrSchaiAhWjFKd+BEEGIYkFVsF8nhO7pEKKwhEjL3/XxAEIEIEQQotgJ0WYO6FxQuqFK iGZmDQ4I0bnKPQAkLCJE86cVUFHObtqxhoVo41lyey+YMWe4CNE0FqIiFqJSFqIjLEQnWGBO+g6E CEIUOyHSz3nRJCm2UuSXEEWQX2C4W+j8H29CpM0jqg2pBBAiACGCENkK0d7N58gNJRtO0eZVnwSE aMWej+lsZQkACUuVEOXT6pxdtJ2FqHTjGXJ7L5gxOyhEC6YU0crMUlqfc4Q2558I9BL5TVEWhAhC VDtCpA37iu08mOQRIk0oMY8IQgQhghBBiOJNiDZxQOeCkvUsRIWaEA2jM5W7AEhYAkKUzkK0jIWo mIVowxlyey+YERCil1iIJrMQLWQhWsZClMdClH/Sd4oyIUQxEaKnWIgkuImAivSpVD5pIh0bMdyz EAV6E2R4lzb3xDBkTettsAqw1f3GY0x7egyy40WI7PKqTiswVK1KNuzKrS0+UIXkrxcU82/6BNM1 LGutFxaLIXO2+WnD3AwE86lJ30W91Lyw/HZyCdG7A+jEyBF0ke/1Sr7nnZ4LZW/2gxBBiCBE8SZE MnfCDbvXn6RNhYdoRtYgKtgzlE5X7gAgYREhmpeeR6tYiLYVH6WSDafJ7b1gxuzhqyFEECL/haiO fs6JKh7VMhMMslW5keNCezjUY4zzWUJlwUw8qvLX94g456XOR6o511TKjOcqMlidh5mUyXlNGlFz g+xUS6WVELnJz7GHyEW9IEQQIggRgBDFuRBtPEtu2L2OhWilJkQfcVC5HYCEJSBEU1mIslmIiliI 1p8mt/eCGbM/Xk3vsxDNn1REKxaU0rrsI7Qp9wRL0UnfWb0QQpQ6QmQYjmW6dLN574jZMDDdMapY mAT8VosqOAfzoXnZ9erU1CUoLMb0QwQo9DhJv3m/XpyemodF+kZBcszPSYic6gUhghBBiACEKEmF 6EM6VbkVgIQlqkI0PyhEy1mIck/6zuoFEKKYCZEENxFQMXUKlU+cQMeGf4xltwFIViEa8A6dGDGc LvK9Xsn3vNNzoewNCBGEKAmFSCqWyEJUuuEsuWHX2pO0cQULUeYgyt8zhE5WbgYgYREhmitCtHQX bV19lIX/NLm9F8yYJULUcxrNm7iaCuaV0Nqlh2ljzvGAFPnNqvkHIUQQIgAAhAgkGCJCQtOmTQdC iOJNiNafITfsWnOCNhYcVIRoU1JQPPDW6qEgtw9c4LgdJAcBIZqSS6uW7KStq8po99pT5PZeMGPW MAgRhAhCBACECEIEUvYdWof69+//tdQSosF0onJDmMyjfs31Y9IfztwQQXqRkZ6mlCVtSPV2VYia DJxXa+UD0SFaQjR3wmrKn1tCa5Ycpg3LjrMUnfCdwnkQotgI0RMXSIKbCKiYMpnKJ4ynYx8PCwjR 0QXT6ExBJgAgCZD7Oe+vLETvsBAN/5gu8r1eyfe803Oh7I3XIUQgOYWoR48e9RJViErWnSE37Cw+ QRvyD9L0hYMob88gOl65LjxKe1AT4yTdtMHOxzbvQUVe97ugSCc+GY7bfceHOgDviBBlTM6lwsU7 aUthGQv/KXJ7L5hRLUTjWYgyWIgWsxBlsxAtO+E7hXMhRIkoREWPd6eCzh0pt9ODlCN0bG/Jsgjx My23+UQ7r0TFrm1yQOLC93DuQw9S3iNdadsACBEAqSlEpQPpWMWasCgaeEtQNG6hJtU9RW1oqtnx JS8osvACFXndHwE15RQhmuNbusdiWAdgTTSE6D0WogwWojwWomIWovUsRBtYYPxmJYQoYYRIgiMJ kk6OGE7b3x1Ay1/pRRkvPE/Tnn6apj71dwBAgjL9madpXo8elNf7Fdr53rt0auQI+lKGzEGIQCoL UVpaWrNEFaLda8+QG3YUnaD1eVVClFv6AR2tKA6D2fSaJkHNn6cpinQ8lGlyfMnziiw8T6u87o+A VTohmu1bukdjWAdgjQjRnEm5tHLRTtq8soyF/xS5vRfMmDmUheifLETjgkK0iIVoKQtR9gnfgRAl lhD9e9JEOjNqJO0dNJDW9OsXkKLFL/WkrH/+EwCQoCx56SXKfeUVWvfmG7Rv8CA6N3pU4F6HEIGU fYe2aNGibyL3EO1ac5rcsH31cVqXe4CmLxAhep/KKlZ7p+S56uC/ycAZuv+u0/w5KlSOndy9jvk3 MILnOu0PpJP55+reqNdK9Gk+lFmVT6FOfGZU5x+yvTotjT/TZEP9CnWCZ6i7cr6Wj6s6mJxfx6LN zNq5mu4fhHfNkpSAEE3MpRVZO2jTiiMs/CfJ7b1gxsyhq1iI0mnO2FWUO2c3FWUdpnVLjgWkyG9W ZByAEMVCiP7OQiTBTQRUTp5ElyZOoM/GjqHjHw+jPR+8T9ve6U+b3n6LNr71JgAgQZF7WO7lvQM/ oBN8b38+biz9h4XIzXOhrN9rECKQfO/QRCuwf0K0yjM1AtCABUW2zajpMareZjw2XCFapUhEA2V4 niYsVfkUDmwQep5huzX6MqvnaOlXEyJEq9zVweG4KjFb5a7c3cO7bslINIVoOQvRahaitSxE61hg /KYAQpQwQiRUsBT9OyhFZ0aOCARPx4YNpaNDAQCJitzDci+fHTUyIENyj8sfQCBEAEKUoEK0s/g0 uWHbquO0dvkBmsZCtLz0PTpSsdIj79FD1T0bz1BhcPskJdi/beA0/Tklz9BtJue43p95v6UcPJRZ dYwqEGr+IWLRXavzNOrb3Gz7SoMQWZdFV0+HOliVT1e36jKYt3F1O3cP57olJyJEs1mICjJ30MaC Iyz8J8ntvWDGjI9YiP7BQjSGhWg2C1EmC9FiFqIlx32nYE7yCJEEASrJKESaFElP0ZcTxtPF8eOo HACQ8Mi9LCIkPUMVLmUIQpS6pKWlNeQY/MFEmmYDIXIUonfpcEWBNzL/qAT26abb6zR/mlaq55Q8 rciCYZ+b/WraxnyDrNQJR7rpdtty1fkjTTI5p1Omy/rb1iFdka+afKz3vUud7NoDVBMNIXqXhWg2 C1HOrN20auFhWrPoGEvRcd8pmJ34QqQJ0K9+9avXfvzjH+fVr19/7n333fcEP5t+UFuCZCpEEuT4 RKXMLwAAJB1enwVlr0OIUpG77rrrbS0O5Pf2TRCiOBOiHUWnyQ1bC4/TmpwqIcopHUCfVOR5YmJ1 T9AvqW+Juu+dmiDeuK/kKUUWnqIVxnSd9me2VnpR3jEt14qBv1REZYrjdrsyq+d0yrQuiy492zqo +djRmiaGtLNVewNBhGjWhFzKX7iDNuQfYeE/SW7vBTMgRN7EQ8rbqVOn+8x+z9dee+0mfnG8061b tztjKUfRFiIAAIAQpS7169fPkHfcV7/61XL0EMWjEK3mgM4FW1eyEC1jIZovQtSfDlXkeOBtpefi SSow7J+gGzY3sWZfyZOKLISe57g/8w+KEL1tWrYCnfhMdNxexUSld0aEI/ScTpnWZXFdR3WfLX+g CaZlM4pRjsfrlrwEhGg8C9ECFqI8FqLCk+T2XjBjxodVQjRrdCHlzNxNhQs+oeKsowEp8pv8WfsT XojkOcS0c/ptX3HFFWdvvvnmaffff383fm79MJqCBCECAECIQLS45pprdgb/6LcRQhSHQrR91Sly w5YVx6g4ez+lzx9Iy0rfpoMV2e5RxcSJ5k9QvnZeyROKLCjb3e7XCdGbpmXLH3izIioTHLdX8SZ1 rC7zzdSnJPScjpnWZdGlZ1cHp/o5oJZHE6fxHtNIVkSIZo5bTnkLttP63MMs/CfI7b1gxnQRohdZ iEaxEM1gIZrPQpTJQpR1zHfyZyauEGm9Q1zmy5jrb7zxxkWunw3B3qNf/epXr6elpTX2W45Chejx CyTDYQAAwEfKXu8LIUox+vfv/zXtPdagQYN0CFEcCtE2DubcsJmFqKhaiN6iAxVLXDOuu/uAp0om gueWPE6Nq4XgcRYCQ9pO+zPvU4Son2nZVGloPHCs6faQc9V869xH4xzSMraBbp9tHfrpxOvVkiWe 2j007/DTSDZEiGawEOUGhWgLC5Hbe8EMEaJ+T42nUf2zaMbQIpo/ejNljttOWeN3+E7G8I3UO/GF 6Ap+Dn2H//mzNm3adL3lllsmffvb3y718pz4xje+caxhw4YT2rZt25Hb4duRBhQQIgAAhAhEA1lQ QXt3yVyipBSili1bviSV69y5870JJ0RPsBAVckDngs0FLERLWYjmDaTs0jdpf0WWS16jDtVBzO9Z HsyP00lT99dcnuuwP/P3JmnqyRt4kyIqY0y3688fQ682r2N6ji4/pTxGIdSd41AH3bnN0yjPpP7V 6ZWkBeSqQ6Z6jFrem1iIsjxcu+QlIERjWYjmsxAtZyFacYLc3gtmTB+yip56oP9nj7ftU/Z8p/c+ +WeXIYf+1W3ooZf/Nuyg7zwy7MA//jZgKb9MGySyEHHZvysBQbdu3e7o0qXLr+UZynLToVmzZu/9 6Ec/WvmVr3zlSzdidMUVV5zjl00TSTeSoAJCBACAEIEoxd4Pau8s+fekFCKtgvKB1kQUoq0rT5Eb NuUfo9VL9tPUgBC9wUHlQndk3qtIRV93x9W5l8WgartZ71LjgaOqz7Pd7yJvvRCNMtl+EzVubhWM 1ZSzilE6WdIPBbypuidIzce5jn0VYTKn+tiS7krPlX27pTqaEC2ft53W5Rxm4T9Bbu8FM6axED38 p2fzW7Zs+ULr1q0f5cC+s/RcSIDvM39t3779n1gifiWr1IhU8Mv08kR6mUpZZcgcP4e+xfxIxI7r 0/y+++77e8OGDcf+4Ac/WOdBhs537dq1Rf/+/a+SdohEiiBEAAAIEYgG6gpz0luUlEIkq0VIBevV q5ebkEK0ggM6F2zKYyFazEI0V4SoH+2rmA9AwhIQojEsRHNZiJaxEOWfILf3ghnTBq+iv/2lR7bI kCwW0KFDhz/KKmrM7/2kc+fOvxMB4AfqbSwVP+F7ua7IRaK8TLUeIgkAROpkPpA8O1mALnoZLidc fvnlF6Ste/To8VPpKWMp+nokgYVRiNZ16/rF2ffeJQAA8JO9L74AIUox5D2nrTAn84mSUogSrZJ6 IZp8YWvBSXLDptyjtHrRvqAQvc5B5VwAEpaAEI3OoeUZ22hd9ie0Oe84ub0XzJg2uJDS/vrSPOm9 YWm5m4Xldn7ZNZK/BPkJp3kr//NmvyQgFgKkIcto33PPPS//7Gc/W6z9ISlcLrvsss9YPh+XNLlN fiHfLwr2EkUsRJJO37S0P819oM2ueW3b7J3zlz8dyPjznw4CAECkzGnDz5O//Hlfv04d3pA5lNJT DiFKbsQNEq3zJKx3qAyV017S8pfbRBKifixEWziYc8NGFqJVQSFaWtqX9lbMBiBhESGazkKUw0K0 loVoEwuR23vBDBGiJzv1miYBOr/k6stQMAnSme/7Cad9rYiQ9AyJDEnvUDzNH1IFSFaCi0SAZMlt Kxlq1arV8yyev5UvfrMQ/VyTQ3m+RVJ27fkoK+BJL5z0yLHk/oW3t4/C8EcAQAohc0dk2HOHDh3+ IMOEe/ToUU96pOW5AyFKXsQNEm16TVjv0ESraIgQ5XNA54KNy1mIsjQh6kN7KmYCkLAEhGgUC9Ec FqKlLES5x8ntvWDGtEGF9PTDr06Uld+C8iLzY66Uvwz5jSxIIPNl5K+KtS1DRgGSOVT169efayUz dlx55ZWn69Wrt/yOO+748L777ntS/t1ChnrIcEQOKO6S+UfcztcF/8p6eaSLKgSfj1cy35OeJxHc Ll26tBQxkkUfAAAgEvjZ1UpGEUhvv3xbTeIxCFHyI3/EbN++/Z9l7m/SClGidYUZhWhz3klyw4Yc FqLMfTQlYyDN2/oPWnPqIwASFhGiaSNZiGZvozVLPmHhP05u7wUz0lmInunad3ywd+g72spvqjBE gwQXoFP8zMxp2rTpwNatWz8SDBbukx6Zn/zkJ8uMx3/9618/IcPkgjL0f0H5/FFwHpUvK+0F5zdd LuP6RbSk90mki+v6P34PfwQApBz/IyIkf2zhZ9YN8rmARPuwNgCW8YH8XyLNIwoRolwO6FywYZkI 0X6aPWM2jc36O41a8DiNmJ/GdKfh8wBIDOQ3O3L+YzQq41maPnI5C9F2FqLDVULk8l4wI31gIT3b te+44PCtbyfaym9uJMgPARLREQG6//77uxl6XX4nfzkV2bnuuuvWWMjQY7KwRLRkSO0lCn4n6Zuy ip/0FslQRQAA8AN+plwT/KPLlegdAkklRIk0j8goRJtyT5Ab1i8ro1VZ+ykrfT1NHLqIPnx7Cr3b ZzT17z2C3n5lOAAJwTuvjqQPXh9PI96fTTPH5NPyjB20Zulh2rD8GLm9F8xIJiHSBEgWhZC5OtES IJkDxNwjq80x/yuic/31168y+QDr8fvuuy9NzpNhctGSIbX+2kp4kn40hj0CAFIXea7I/E/IEEg6 IVLnEcX7F2hDhGg5B3QukB6iokUHKXvmFpoxOo/GDJpHw9+dSUP7TwMgYRj2znQa9cEcmjR0MS2Y VEz583bTWhaijTnHye29YEYiC5FfAiTLYN9www0FLgXoTlmJL7hy3i9lqGHDhg3HmcmQLGUu54s0 BecMiQxdHe2hJtEe7ggASG0QRIOkEyIx/quuuupo3bp193NA8VwiCdHGnBPkhg3LjgeGFuXPLaFF 6RsoY1whi1E+TR+ZS9NGLAcgIZDf66wxK2j+xGJaNnMbrco8QOuWlgV+327vBTOmfpA4QqQI0C/u u+++J26++eZpkQjQ7bffPlTm9rjoAbpDEaD/5ufQj2VScXAIyfeM3yJiGTomYiVD6YIyJOddHwsZ AgAAAIBHIRJkZalEKLBRiDYsE9lxx7qlR6ko6xMqmLeHls/eRctm7aDsmdsBSChyZu+k3IzdVLjw AK1ZfITWZR8jL/eBGfEsRGYCJH/AiaUASbsEl5iVFeG+JwtPBFfi+4Ysly3/rq4qJzLUpk2brpJm 8FtDvwyeCxkCAAAA4lWIEoUQIcrmgM4l65ceZyk6RmsWHWExOkxFmZ8AkHjwb7d40WFau7gs8Hv2 cg9YMfX9+BGiaAqQLGrggwB9TVs2PIis6vYt+e5Pw4YNxzZr1uyD9u3bt4UMAQAASFTkj3ryToQQ JYgQrc8+Tl6RIBKAZCCc378ZU95fWWtCFMseoC5duvzGgwBdzfJzlaykpAmQPH+05ci1ssvk4uCK Sz+WlezkGx0yL1M+XMj/fTNkCAAAQCIhi/5on+Rp0KBBOoQoEYRo6XECAERGLIUo1gIUlJOAAMnC C5EIkFld5DhZ4lrmE4kAiRSJaAW/6fRDyBAAAIBEQt6p2rs23tcWgBAFhWjdkuMEAIiMKe9FT4ii JECPuekBCgpQA78EyKxuco4Mo5N2CwqQLLbwI/7v/yeiJGlDhgAAACQK119//Wrt+6SJssZAagvR 4yxEizmgAwBEhJ9CpAnQM88885P777//b7feeuv4q6+++oBXAfrKV77y5XXXXVfcqFGjUffee+/T 4QpQcBU4XwTIqr6SlkhRsKfo6uA/r5ThdJAhAAAAiYKMcNDew/Xr189IlXrb7pSAIt6FaC0HcwCA yJgcgRAlggCpHxKMVICs2kDSDn4M9TJNtvCtDgAAAImESJD2Xm7fvv2fU1qI2A6b1atXLzceu8qM QrRmkawaBwCIhMnvhidEHTp0aBNHAvQtKwGKhgTZySFeqgAAABINtXfo2muv3ZhKdTfdKEaoNYh8 tT2uhSiLAzoAQER4FSLZJ5LBz4fBPgnQvfIBUxaglokkQAAAAECy0KRJk49TsXfIUogEbdJzvPUS aULUs0ev5n0fnfjlpAErCQAQGYP+Md+TEIlwBAWkfaQCFFwF7q60tLSmskKbJkAyBA8CBAAAAEQf ifW1pbZTrXfIVohkmb147CWSwEe+DM/B0PXPPdLn/b93fmXyEx1fnvHEg/+a/diDL80BALhH7pvH O7w86+8PvZL+aNcnH2ARuVG+PyCyYScY2spqIi0WAvSMhQD9xihAnMYtskS1pCX3tQgQS9l3g4sT fAMCBAAAAEQXifW19zm/ax+EEAWRYCcee4kkEJIAScojgZQEVxxo3de+ffs/SfceAMATf+L7p7X0 1LCcNAkOS/uWLArgQoi+LvdhixYt+rZu3bq7yI7fAiTlgAABAAAA0UXmD8mCChL7iwNAiBTUXqKG DRuOi4sCV61mdYUMoZGASi6gLAIRnHMAAPBOc76HbgsOU5Phad9wWiFNEyI5Xr4vJGmw/PyaRege PwUIEgQAAADEDhklkor1tt2p9hIJIh7xUOjgNz++LkGVBFjyV23mp/zvPwMAeEZE5YbgB0tdfUg0 OIco8IcJuf9EekR+5A8U6hwgCBAAAAAAElqIBBlHGG9L8Bk+hCgB1reCwRYAIDy+KX9kEBly+/0c uQeD9981wcUPbtAWQYAAAQAAACBphEi48cYbF2lSJMPo4kWKJKiS4E0CLQBA+GgfEvUyV0dbaS44 p0/E55sQIAAAAAAkpRBxYHOTLKzQoEGD9Hj7UKsmRwCAyAj33hORElSpggABAAAAIKmESJB5Amgw AICdHKEdAAAAgPgnFVeS80WIAAAAAAAAAImNfBrjiiuuONu6devH0R4QIgAAAAAAAFIGmfqiriAt coR2gRABAAAAAACQEtSrVy833r4xCiECAAAAAAAARJ0WLVr01WTommuu2Yl5RD4KkaxAFy8fbAUA AAAAAADo6dq1awtNhmTlaInf0S4+CVGbNm26SqPKWMR4XI4bAAAAAACAVMY4b0jid7SLj0IkYw+1 xpUxieh6AwAAAAAAID6Q2BzzhqIsRNLI119//WqtkevXr5+BRgUAAAAAAKD2kdhci9Ovvfbajei8 iIIQCfLB1rp16+7XGrtJkyYfo2EBAAAAAACoXbTRXBKrS8yONomSEAkyMUs+8KRJkaxigcYFAAAA AACgdmnZsuVLWEQhBkIkyEpzssACJmwBAAAAAAAAUk6IBPnarSZE+PotAAAAAAAAIKWESJCeISyy AAAAAAAAAEhJIRJkDpGsPoeVLAAAAAAAAIguWDAhDoVIgAwBAAAAAAAQXWSFZ5nHn5aW1hDtEWdC BAAAAAAAAIgO0vnQoEGDdG2qylVXXXUUHRIQIgAAAAAAAJKenj171r3xxhsXaTIkn7/BYmYJJkTS pYduPQAAAAAAALzH0ddcc81OtWcIcXWCCZEYrXwtV8Y6tmrV6jlcBAAAAAAAAJyR2Fn97qeIERZU SEAhkgupfqtIuvtEknAxAAAAAAAACEViZfmcjRpDN2zYcBzmDCWoEAmtW7d+XLVb6err2rVrC1wQ AAAAAAAA9MgnbbS4WWJo+e4n2iXBhUgwjn8UmjZtOhC9RQAAAAAAANQgPUHyjU+JnZ955pmb0CZJ IkSCyI+6XKDWW9SuXbsHcXEAAAAAAACojpu/jyFySShEGtLtJ8sFqmIEKQIAAAAAAACkhBAFrbeu fGlXZOjaa6/dCAMGAAAAAACpgMS96AyAEFWTlpbWTMDFAQAAAAAAyS5CsgKzTBmRTgEsMgYhAgAA AAAAIOmRkVGqCGnUq1cvF+0DIXKFDK1r2bLlS1iRDgAAAAAAJJIIyRLaxrnz2neFZOEEtBOEyBFZ rlv74ciPSeQIQ+wAAAAAAEC8IktlS8xqFCH5ppB8dqZHjx710E4QItfIhDMzq65bt+5+MW78oAAA AAAAQDyhLRxmFCH0CEGIwsauu1GQD1e1bt36cQypAwAAAAAAtY2MZtK+tykxLGJUCJGvtG/f/s/y cVcxbaN548cGAAAAAACihawSJ7GoLJDgdGznzp3vRZtBiKL+g5QPvNavXz9DhEgkye54kSV86wgA AAAAAHiJN2VpbOnlkRFJ6h/j8Yd4CFFcIeMxneYSyVwkbWEGWeJQxnHKynXyI8d4TgAAAAAAIHGh xIgSK1pN1dCQniK0GYQoobjrrrvetvtRqzjJldwkbpAbyi4d6Up1m5ZTt6vIndu0nNrKbTqSp1/1 k9UE7dLSHk5OuOgp/L7bMkkPpF1ast9tWk7SLeX24zcl7Vgbvymn+vl1z9RW/XDP4J5xUz8/75lE fybgnsE9k6j3jPYHdCskDektwgdVIUQJiVi8rPcuP+RIhcitWDm9FORB4TYtp4eK1M1tWo4/Epfp SJ5+1c/pweLmummrD9qlI9fWbZnkgWeXluz3S7Kl3H78pqQda+M3Fat7prbqh3sG94yb+vl5zyT6 MwH3DO6ZRL1ntM+9yNx0OVbKCAGCECUt8pcG+XHLXydkaUQvf4WAEOFFBSGCEOGeQXAHIcI9g3sm +e4ZmTOEqRQQIgAAAAAAAACAEAEAAAAAAAAAhAgAAAAAAAAAIEQAAAAAAAAAACECAAAAAAAAAAgR AAAAAAAAAECIAAAAAAAAAABCBAAAAAAAAADxy/8PbXgcc4I9Si8AAAAASUVORK5CYII= --047d7bdc939c5e57c004e4efde9f-- From Christian.Groves@nteczone.com Tue Aug 27 20:49:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE2E11E8126 for ; Tue, 27 Aug 2013 20:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e53m1GzLDV+T for ; Tue, 27 Aug 2013 20:48:59 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id DCBF411E8128 for ; Tue, 27 Aug 2013 20:48:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAL9yHVJ20fce/2dsb2JhbAANTcQ2gTqDGAEBAQMBMgEFGxUGBAYGCwsRAwEBAQEJFggHCQMCAQIBDyUJCBMGAgEBF4dUAwmlSIlADYlqjHmBIoEWOgaEEwOTVEGBcY4diF6BXw Received: from ppp118-209-247-30.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.247.30]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Aug 2013 13:18:44 +0930 Message-ID: <521D7313.6030609@nteczone.com> Date: Wed, 28 Aug 2013 13:48:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 03:49:01 -0000 Hello Mary, Please see my responses below. Regards, Christian On 28/08/2013 1:53 AM, Mary Barnes wrote: > Hi folks, > > In reviewing the FW in order to tease out specific security threats > that a CLUE solution must address, I came up with a set of comments > that I would like the WG to consider. Below is the thread of > discussion. Additional feedback (both agreeing with the proposal or > not - with details if you don't agree) from the WG is necessary in > order for Mark to include these changes. As noted, I will provide some > concrete text to go along with a couple of the suggestions. Please > send feedback no later than Sept. 3rd CoB. No responses will be > interpreted as support for the changes. > > Of course, there will be an opportunity to provide comments on the > updated version of the document as well later, but it's always helpful > to get that feedback before incorporating changes. > > Regards, > Mary > --as an individual > > ---------- Forwarded message ---------- > From: *Mary Barnes* > > Date: Tue, Aug 27, 2013 at 10:18 AM > Subject: Re: Comments on CLUE Framework > To: "Duckworth, Mark" > > Cc: Paul Kyzivat > > > > Thanks for the response. I have a few responses below [MB]. I will > forward the comments to the list to get feedback from the WG. > > Mary. > > > On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark > > wrote: > > Hi Mary, > > Thanks for the good suggestions. In general, all your suggestions > make sense to me. > > More comments below. > > Mark > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > *Sent:* Wednesday, August 21, 2013 2:23 PM > *To:* Duckworth, Mark > *Cc:* Paul Kyzivat > *Subject:* Comments on CLUE Framework > > So, here are the comments I have on the framework based on my > re-read to tease out specifics for the security requirements. One > major thing I noticed is that some of the structural concerns I > have are with regards to some of the bigger changes made between > the -08 and -09. Again, I looked at diffs after the various > revisions were submitted and thought the content was okay at the > time. But, as I'm now re-reading from beginning to the end (for > the first time in a long time), there are some areas that I really > stumbled over and I think some more reorganization/editorial work > is needed before we could forward this doc for publication. Having > been a gen-art reviewer for a decade, I think similar issues would > be raised on the document by other directorate reviewers (and ADs) > if we don't make a few changes. I wanted to vet these with you > prior to posting to the WG mailing list. > > Paul - I'm reviewing this from the perspective that was discussed > on WG chairs mailing list with regards to doing multiple reviews > as part of the PROTO process. > > Mary. > > Comments: > > =========== > > Major: > > ------- > > 1) The abstract needs some beefing up, including setting some > context. Per my comment 3 below, I think it's important to > highlight that the protocol outlined in this document augments and > does not replace SIP O/A. I would suggest to update the text in > the Abstract something like the following. : > > OLD: > > This document offers a framework for a protocol that enables > > devices in a telepresence conference to interoperate by specifying > > the relationships between multiple media streams. > > NEW: > > This document defines a framework for a protocol to enable devices > in a telepresence conference to interoperate. The protocol enables > communication of information about multiple media streams so a > sending system, receiving system or intermediate system can make > reasonable decisions about transmitting, selecting and rendering > the media streams. This protocol is used in addition to SIP > signaling for setting up a telepresence session. > > */[Duckworth, Mark] sounds good./* > /*[CNG] CLUE is point to point, (i.e. sent from one endpoint and terminated at another)*/ so there is no intermediate system from a CLUE perspective. I would strike the text regarding intermediate system. > 2) Introduction: I really stumbled over the level of detail that > the document jumps into in the Introduction (which is before any > terminology). It goes from a high level description of the > problem, highlighting that this document provides a framework > based on the use cases and requirements, directly to the > statement: "Conceptually distinguished are Media Providers and > Media Consumers". I also think the level of detail does not belong > in the introduction. To me that's more overview/motivation. > Previously, the introduction provided some text as to what is in > the remainder of the document. I think some of the old text needs > to be pulled back into this introduction and the text starting > with the "Conceptually" paragraph might serve very well in a > "Motivation" section just prior to the overview (after the > terminology section). I also think the "Conceptually" sentence > could be replaced with text that provides a better introduction to > the section, perhaps linking the term "consumer" to "receiver" and > "provider" to "sender" that are mentioned in the abstract text I > suggested above. Maybe something like the following: > > OLD: > > Conceptually distinguished are Media Providers and Media Consumers. > > NEW: > > This document introduces the term Media Provider to represent the > entity that is sending the media and Media Consumer to represent > the entity that is receiving the media. > > */[Duckworth, Mark] sounds good. But it will take some work to > figure out detailed changes between introduction and overview, and > bringing back some old text./* > > [MB] Yeah, I know. I can make a pass at that if you would find that > helpful. [/MB] [CNG] OK in theory, I'll wait for the concrete text. > > *//* > > 3) The fact that SIP and SDP offer/answer are used for basic > session setup as well as when needed during the session (as > described in detail in solution documents) isn't highlighted early > enough or often enough. Given we've had lots of folks thinking we > were trying to invent something new entirely, I think it's really > important for this be quite explicit early on. I think this > relates to additional text that should be in the introduction. I > think something like the following will be sufficient: > > NEW: > > This document identifies the protocols necessary to achieve the > functionality per the use cases and requirements. The basic > session setup for the use cases is based on SIP [RFC 3261] and SDP > offer/answer [RFC 3264]. The details with regards to this > signaling are provided in the solution documents. In addition to > basic SIP & SDP offer/answer, CLUE specific signaling is required > to exchange the information describing the multiple media streams. > The details of this signaling and the information required to be > exchanged is described in subsequent sections of this document. > > */[Duckworth, Mark] sounds good. We tried to say this about using > SDP O/A, but not until the end of section 4. It does seem better > to say it earlier./* > /*[CNG] I think we should also make it clear that whilst "SIP and SDP O/A" are mainly discussed it does not prevent CLUE from being used in networks where there are other call controls i.e. H.32x, WebRTC, what ever the future holds.... */ > > Minor: > > -------- > > 1) General: I realize that at some point, someone changed all the > terms to appear as formal names - e..g., capitalized. Personally, > I prefer just having the terms all lower case as I find it easier > to read that way. However, the RFC editor leaves the choice to the > document editor, but it needs to be consistent. So, another pass > is needed as I noticed a few that weren't caps that should be and > some that were caps that shouldn't be. For example, in the > "Conceptually" paragraph I refer to above, "Renderer" is in Caps, > but it's not defined as a reserved word in the terminology and I'm > assuming that the intent is to only have nouns in all caps? You > will find it awkward if you try to change every occurrence of the > reserved words as sometimes it just won't read right (which is > another reason to just use lower case). > > */[Duckworth, Mark] I don’t care either way. I think it was > Stephan who first suggested capitals, in the old terminology > document./* > > [MB] Again, either way is okay. But, there are some places where it's > not all caps. I also think using lower case is easier just from a > basic editing standpoint as it's more natural IMHO to just type the > words and not have to CAP. [/MB] [CNG] It can be helpful to have capitalised terms to distinguish when you're talking about a entity Renderer vs a function "render". > *//* > > 2) Introduction: The text in the intro (3rd para) (that I'm > suggesting to move to Motivation section) that starts with > "Motivations" reads a little funky. I suggest to reword something > like: > > OLD: > > Motivations for this document (and, in fact, for the existence ofthe CLUE protocol) include: > > NEW: > > > > The motivations for the framework outlined in this document include the following: > > */[Duckworth, Mark] sounds good/* > /*[CNG] OK*/ > > 3) Introduction: List item (1). I was going to suggest rewording > (as it reads as if the endpoints described are only specific to > this document), but it's not clear to me exactly what that item is > trying to say. Can it be changed to something like the following > and still mean what is intended? [As an aside "Media Renderer" > isn't a reserved word - I think perhaps if you add a definition > for "Renderer" that would help. I actually think that's probably > necessary anyways as I think it's important to distinguish "Media > Renderer" from "Media Consumer"]. > > OLD: > > (1) Endpoints according to this document can, and usually do, have multiple Media Captures and Media Renderers, that is, for example,multiple cameras and screens. While previous system designs were able to set up calls that would light up all screens and cameras > > (or equivalent), what was missing was a mechanism that can associate the Media Captures with each other in space and time. > > NEW: > > > > (1) Endpoints in telepresence systems typically have multiple Media Captures and Media Renderers, e.g., multiple cameras and screens. While previous system designs were able to set up calls that would capture media using all cameras and display media on all screens, for example, there is no mechanism that can associate these Media Captures with each other in space and time. > > > > */[Duckworth, Mark] Yes, I think that says the intent better./* > /*[CNG] */I'd propose a slight reword "Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. ..." > > > 4) Section 4, last two paragraphs. I'm really wondering how much > needs to be said (if anything) about "legacy" in this document. > This document is defining what we need for CLUE. The signaling > solution document will of course get into how this works. But, I > think we could just delete the next to last paragraph and condense > the one on RTP to reference the WG RTP mapping mapping document > > */[Duckworth, Mark] okay/* > /*[CNG] I don't think one paragraph describing this fall back in the framework is too much. I think its helpful to explain fallback behaviour. */ > > 5) Somewhat General. There was a diagram in Section 5 in the -02 > version that was dropped in the -03. I really think that more > diagrams would help to understand this stuff. > > */[Duckworth, Mark] That was the precursor to this. The -02 > diagram doesn’t really say much, but I could try to update it. The > one below is a bit much to convert to ASCII./* > > [MB] I can convert that to ascii art. I did all the diagrams in RFC > 5239. This is just a tad more complicated than some of those. [/MB] > > *//* > > *//* > > 6) Per my other email, I believe these should all be normative > references and RFC 3264 needs to be added. > > [CNG] ??? From mary.ietf.barnes@gmail.com Wed Aug 28 14:59:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4581621E8055 for ; Wed, 28 Aug 2013 14:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.267 X-Spam-Level: X-Spam-Status: No, score=-101.267 tagged_above=-999 required=5 tests=[AWL=-0.934, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, 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 BxaahOIlIv4o for ; Wed, 28 Aug 2013 14:59:02 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 60FA121E8056 for ; Wed, 28 Aug 2013 14:59:02 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id j7so2268325qaq.13 for ; Wed, 28 Aug 2013 14:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NxGyJjLZddadLiYkR3pdT/9CkdqdM8o7Vi3ezk1OJew=; b=XPs2UTrAyg10oL/QjNimCSv4Go3V7XK36XhLyfdHMPo4KjGYQp/NPtriHHSCP89f1/ EOAgIjhV42h31RVsNoksDh6pV1Qx/sZWVckc886TaITYOGSHXEDNPUdH4MByW4TgY5nd jt7+eU/7qapZnWAOaLMDetPF5NapDRnLyLlrTmOq/9ncoJYk/Pe9SiNZWK4X5Jh0Z9uU ijS3favEkMHMVal6z5bkleRi29/bxuY4N0KUKI1LulhS5MpPd4D+vpwDOlb8FlSFCayz U4t3q2saFgIVqJQzcmMIe4XXVLjSM4W3n1GpRl8jtXZTZiyEWkkpp3aFdsdPRnopiriO AUiA== MIME-Version: 1.0 X-Received: by 10.224.73.137 with SMTP id q9mr1015875qaj.13.1377727138366; Wed, 28 Aug 2013 14:58:58 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 28 Aug 2013 14:58:58 -0700 (PDT) In-Reply-To: <521D7313.6030609@nteczone.com> References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> <521D7313.6030609@nteczone.com> Date: Wed, 28 Aug 2013 16:58:58 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c3bed4ae0e7704e50918b4 Cc: CLUE Subject: Re: [clue] Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 21:59:05 -0000 --001a11c3bed4ae0e7704e50918b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable HI Christian, Thanks for your comments - my responses are below [MB2]. Mary. On Tue, Aug 27, 2013 at 10:48 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mary, > > Please see my responses below. > > Regards, Christian > > > On 28/08/2013 1:53 AM, Mary Barnes wrote: > >> Hi folks, >> >> In reviewing the FW in order to tease out specific security threats that >> a CLUE solution must address, I came up with a set of comments that I wo= uld >> like the WG to consider. Below is the thread of discussion. Additional >> feedback (both agreeing with the proposal or not - with details if you >> don't agree) from the WG is necessary in order for Mark to include these >> changes. As noted, I will provide some concrete text to go along with a >> couple of the suggestions. Please send feedback no later than Sept. 3rd >> CoB. No responses will be interpreted as support for the changes. >> >> Of course, there will be an opportunity to provide comments on the >> updated version of the document as well later, but it's always helpful t= o >> get that feedback before incorporating changes. >> >> Regards, >> Mary >> --as an individual >> >> ---------- Forwarded message ---------- >> From: *Mary Barnes* > **gmail.com >> >> Date: Tue, Aug 27, 2013 at 10:18 AM >> Subject: Re: Comments on CLUE Framework >> To: "Duckworth, Mark" > **polycom.com >> >> Cc: Paul Kyzivat **= > >> >> >> Thanks for the response. I have a few responses below [MB]. I will >> forward the comments to the list to get feedback from the WG. >> >> Mary. >> >> >> On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark < >> Mark.Duckworth@polycom.com >> >> wrote: >> >> Hi Mary, >> >> Thanks for the good suggestions. In general, all your suggestions >> make sense to me. >> >> More comments below. >> >> Mark >> >> *From:*Mary Barnes [mailto:mary.ietf.barnes@**gmail.com >> >] >> *Sent:* Wednesday, August 21, 2013 2:23 PM >> *To:* Duckworth, Mark >> *Cc:* Paul Kyzivat >> *Subject:* Comments on CLUE Framework >> >> >> So, here are the comments I have on the framework based on my >> re-read to tease out specifics for the security requirements. One >> major thing I noticed is that some of the structural concerns I >> have are with regards to some of the bigger changes made between >> the -08 and -09. Again, I looked at diffs after the various >> revisions were submitted and thought the content was okay at the >> time. But, as I'm now re-reading from beginning to the end (for >> the first time in a long time), there are some areas that I really >> stumbled over and I think some more reorganization/editorial work >> is needed before we could forward this doc for publication. Having >> been a gen-art reviewer for a decade, I think similar issues would >> be raised on the document by other directorate reviewers (and ADs) >> if we don't make a few changes. I wanted to vet these with you >> prior to posting to the WG mailing list. >> >> Paul - I'm reviewing this from the perspective that was discussed >> on WG chairs mailing list with regards to doing multiple reviews >> as part of the PROTO process. >> >> Mary. >> >> Comments: >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Major: >> >> ------- >> >> 1) The abstract needs some beefing up, including setting some >> context. Per my comment 3 below, I think it's important to >> highlight that the protocol outlined in this document augments and >> does not replace SIP O/A. I would suggest to update the text in >> the Abstract something like the following. : >> >> OLD: >> >> This document offers a framework for a protocol that enables >> >> devices in a telepresence conference to interoperate by specifyi= ng >> >> the relationships between multiple media streams. >> >> NEW: >> >> This document defines a framework for a protocol to enable devices >> in a telepresence conference to interoperate. The protocol enables >> communication of information about multiple media streams so a >> sending system, receiving system or intermediate system can make >> reasonable decisions about transmitting, selecting and rendering >> the media streams. This protocol is used in addition to SIP >> signaling for setting up a telepresence session. >> >> */[Duckworth, Mark] sounds good./* >> >> /*[CNG] CLUE is point to point, (i.e. sent from one endpoint and > terminated at another)*/ so there is no intermediate system from a CLUE > perspective. I would strike the text regarding intermediate system. > [MB2] My understanding was that intermediate system is something line an MCU or conference focus. However, I think you are correct in that sending system and receiving system are sufficient. I also double checked and we don't use the term intermediate system in the requirements or use cases expect in the Heterogeneous system use case when it's talking about transcoding. [/MB2] > > 2) Introduction: I really stumbled over the level of detail that >> the document jumps into in the Introduction (which is before any >> terminology). It goes from a high level description of the >> problem, highlighting that this document provides a framework >> based on the use cases and requirements, directly to the >> statement: "Conceptually distinguished are Media Providers and >> Media Consumers". I also think the level of detail does not belong >> in the introduction. To me that's more overview/motivation. >> Previously, the introduction provided some text as to what is in >> the remainder of the document. I think some of the old text needs >> to be pulled back into this introduction and the text starting >> with the "Conceptually" paragraph might serve very well in a >> "Motivation" section just prior to the overview (after the >> terminology section). I also think the "Conceptually" sentence >> could be replaced with text that provides a better introduction to >> the section, perhaps linking the term "consumer" to "receiver" and >> "provider" to "sender" that are mentioned in the abstract text I >> suggested above. Maybe something like the following: >> >> OLD: >> >> Conceptually distinguished are Media Providers and Media Consumers. >> >> NEW: >> >> This document introduces the term Media Provider to represent the >> entity that is sending the media and Media Consumer to represent >> the entity that is receiving the media. >> >> */[Duckworth, Mark] sounds good. But it will take some work to >> >> figure out detailed changes between introduction and overview, and >> bringing back some old text./* >> >> >> [MB] Yeah, I know. I can make a pass at that if you would find that >> helpful. [/MB] >> > [CNG] OK in theory, I'll wait for the concrete text. > >> >> *//* >> >> >> 3) The fact that SIP and SDP offer/answer are used for basic >> session setup as well as when needed during the session (as >> described in detail in solution documents) isn't highlighted early >> enough or often enough. Given we've had lots of folks thinking we >> were trying to invent something new entirely, I think it's really >> important for this be quite explicit early on. I think this >> relates to additional text that should be in the introduction. I >> think something like the following will be sufficient: >> >> NEW: >> >> This document identifies the protocols necessary to achieve the >> functionality per the use cases and requirements. The basic >> session setup for the use cases is based on SIP [RFC 3261] and SDP >> offer/answer [RFC 3264]. The details with regards to this >> signaling are provided in the solution documents. In addition to >> basic SIP & SDP offer/answer, CLUE specific signaling is required >> to exchange the information describing the multiple media streams. >> The details of this signaling and the information required to be >> exchanged is described in subsequent sections of this document. >> >> */[Duckworth, Mark] sounds good. We tried to say this about using >> >> SDP O/A, but not until the end of section 4. It does seem better >> to say it earlier./* >> >> /*[CNG] I think we should also make it clear that whilst "SIP and SDP > O/A" are mainly discussed it does not prevent CLUE from being used in > networks where there are other call controls i.e. H.32x, WebRTC, what eve= r > the future holds.... */ > [MB2] I don't disagree with what you say but I don't think we should say anything about that given our charter, which limits the work to SIP. That's opening up the question as to how that will work, whether additional specification is required,etc. [/MB2] > >> Minor: >> >> -------- >> >> 1) General: I realize that at some point, someone changed all the >> terms to appear as formal names - e..g., capitalized. Personally, >> I prefer just having the terms all lower case as I find it easier >> to read that way. However, the RFC editor leaves the choice to the >> document editor, but it needs to be consistent. So, another pass >> is needed as I noticed a few that weren't caps that should be and >> some that were caps that shouldn't be. For example, in the >> "Conceptually" paragraph I refer to above, "Renderer" is in Caps, >> but it's not defined as a reserved word in the terminology and I'm >> assuming that the intent is to only have nouns in all caps? You >> will find it awkward if you try to change every occurrence of the >> reserved words as sometimes it just won't read right (which is >> another reason to just use lower case). >> >> */[Duckworth, Mark] I don=92t care either way. I think it was >> >> Stephan who first suggested capitals, in the old terminology >> document./* >> >> >> [MB] Again, either way is okay. But, there are some places where it's no= t >> all caps. I also think using lower case is easier just from a basic edit= ing >> standpoint as it's more natural IMHO to just type the words and not have= to >> CAP. [/MB] >> > [CNG] It can be helpful to have capitalised terms to distinguish when > you're talking about a entity Renderer vs a function "render". > > *//* >> >> >> 2) Introduction: The text in the intro (3rd para) (that I'm >> suggesting to move to Motivation section) that starts with >> "Motivations" reads a little funky. I suggest to reword something >> like: >> >> OLD: >> >> Motivations for this document (and, in fact, for the existence >> ofthe CLUE protocol) include: >> >> >> NEW: >> >> >> The motivations for the framework outlined in this document include >> the following: >> >> */[Duckworth, Mark] sounds good/* >> >> /*[CNG] OK*/ > >> >> 3) Introduction: List item (1). I was going to suggest rewording >> (as it reads as if the endpoints described are only specific to >> this document), but it's not clear to me exactly what that item is >> trying to say. Can it be changed to something like the following >> and still mean what is intended? [As an aside "Media Renderer" >> isn't a reserved word - I think perhaps if you add a definition >> for "Renderer" that would help. I actually think that's probably >> necessary anyways as I think it's important to distinguish "Media >> Renderer" from "Media Consumer"]. >> >> OLD: >> >> (1) Endpoints according to this document can, and usually do, have >> multiple Media Captures and Media Renderers, that is, for example,multip= le >> cameras and screens. While previous system designs were able to set up >> calls that would light up all screens and cameras >> >> (or equivalent), what was missing was a mechanism that can associate >> the Media Captures with each other in space and time. >> >> NEW: >> >> >> (1) Endpoints in telepresence systems typically have multiple Media >> Captures and Media Renderers, e.g., multiple cameras and screens. While >> previous system designs were able to set up calls that would capture med= ia >> using all cameras and display media on all screens, for example, there i= s >> no mechanism that can associate these Media Captures with each other in >> space and time. >> >> >> */[Duckworth, Mark] Yes, I think that says the intent better./* >> >> /*[CNG] */I'd propose a slight reword "Endpoints in telepresence system= s > typically have multiple Media Capture and Media Render devices, e.g., > multiple cameras and screens. ..." > [MB2] That sounds good to me. [/MB] > > >> 4) Section 4, last two paragraphs. I'm really wondering how much >> needs to be said (if anything) about "legacy" in this document. >> This document is defining what we need for CLUE. The signaling >> solution document will of course get into how this works. But, I >> think we could just delete the next to last paragraph and condense >> the one on RTP to reference the WG RTP mapping mapping document >> >> */[Duckworth, Mark] okay/* >> >> /*[CNG] I don't think one paragraph describing this fall back in the > framework is too much. I think its helpful to explain fallback behaviour.= */ > [MB2] If you read it in the context of that section, it doesn't quite seem to fit. It leaves more questions than providing answers in my opinion. It seems to be some leftover text from when the document had a lot more detail - e.g., the text about legacy devices is totally unnecessary as they aren't referenced elsewhere in the framework any longer. I think perhaps the idea of fallback when the device doesn't support CLUE can be stated much more concisely. I don't have a proposal right off, but will think about it. Unless someone else has suggestions. [/MB2] > >> 5) Somewhat General. There was a diagram in Section 5 in the -02 >> version that was dropped in the -03. I really think that more >> diagrams would help to understand this stuff. >> >> */[Duckworth, Mark] That was the precursor to this. The -02 >> >> diagram doesn=92t really say much, but I could try to update it. The >> one below is a bit much to convert to ASCII./* >> >> >> [MB] I can convert that to ascii art. I did all the diagrams in RFC 5239= . >> This is just a tad more complicated than some of those. [/MB] >> >> *//* >> >> *//* >> >> >> 6) Per my other email, I believe these should all be normative >> references and RFC 3264 needs to be added. >> >> >> [CNG] ??? > [MB2] Sorry, there was another email exchange that I hadn't yet sent to the list about making this document standards track and adding some more references. I'll send that now. [/MB2] > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --001a11c3bed4ae0e7704e50918b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
HI Christian,

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

Mary.


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

Please see my responses below.

Regards, Christian


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

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

Of course, there will be an opportunity to provide comments on the updated = version of the document as well later, but it's always helpful to get t= hat feedback before incorporating changes.

Regards,
Mary
--as an individual

---------- Forwarded message ----------
From: *Mary Barnes* <mary.ietf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.c= om>>
Date: Tue, Aug 27, 2013 at 10:18 AM
Subject: Re: Comments on CLUE Framework
To: "Duckworth, Mark" <Mark.Duckworth@polycom.com <mailto:Mark.Duckworth@= polycom.com>>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>>


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

Mary.


On Mon, Aug 26, 2013 at 4:26 PM, Duckworth, Mark <Mark.Duckworth@polycom.com &l= t;mailto:Ma= rk.Duckworth@polycom.com>> wrote:

=A0 =A0 Hi Mary,

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

=A0 =A0 More comments below.

=A0 =A0 Mark

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


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

=A0 =A0 Paul - I'm reviewing this from the perspective that was discuss= ed
=A0 =A0 on WG chairs mailing list with regards to doing multiple reviews =A0 =A0 as part of the PROTO process.

=A0 =A0 Mary.

=A0 =A0 Comments:

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

=A0 =A0 Major:

=A0 =A0 -------

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

=A0 =A0 OLD:

=A0 =A0 =A0 =A0 =A0This document offers a framework for a protocol that ena= bles

=A0 =A0 =A0 =A0 devices in a telepresence conference to interoperate by spe= cifying

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

=A0 =A0 NEW:

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

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

/*[CNG] CLUE is point to point, (i.e. sent from one endpoint and terminated= at another)*/ so there is no intermediate system from a CLUE perspective. = I would strike the text regarding intermediate system.
[MB2] My understanding was that intermediate system is something line = an MCU or conference focus. =A0 However, I think you are correct in that se= nding system and receiving system are sufficient. I also double checked and= we don't use the term intermediate system in the requirements or use c= ases expect in the Heterogeneous system use case when it's talking abou= t transcoding. =A0[/MB2]

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

=A0 =A0 OLD:

=A0 =A0 Conceptually distinguished are Media Providers and Media Consumers.=

=A0 =A0 NEW:

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

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

=A0 =A0 figure out detailed changes between introduction and overview, and<= br>
=A0 =A0 bringing back some old text./*


[MB] Yeah, I know. I can make a pass at that if you would find that helpful= . [/MB]
[CNG] OK in theory, I'll wait for the concrete text.

=A0 =A0 *//*


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

=A0 =A0 NEW:

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

=A0 =A0 */[Duckworth, Mark] sounds good. We tried to say this about using
=A0 =A0 SDP O/A, but not until the end of section 4. It does seem better
=A0 =A0 to say it earlier./*

/*[CNG] I think we should also make it clear that whilst "SIP and SDP = O/A" are mainly discussed it does not prevent CLUE from being used in = networks where there are other call controls i.e. H.32x, WebRTC, what ever = the future holds.... */
[MB2] I don't disagree with what you say but I don= 9;t think we should say anything about that given our charter, which limits= the work to SIP. That's opening up the question as to how that will wo= rk, whether additional specification is required,etc. =A0[/MB2]=A0

=A0 =A0 Minor:

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

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

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

=A0 =A0 Stephan who first suggested capitals, in the old terminology
=A0 =A0 document./*


[MB] Again, either way is okay. But, there are some places where it's n= ot all caps. I also think using lower case is easier just from a basic edit= ing standpoint as it's more natural IMHO to just type the words and not= have to CAP. [/MB]
[CNG] It can be helpful to have capitalised terms to distinguish when you&#= 39;re talking about a entity Renderer vs a function "render".

=A0 =A0 *//*


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

=A0 =A0 OLD:

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


=A0 =A0 NEW:

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

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

/*[CNG] OK*/

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

=A0 =A0 OLD:

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

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

=A0 =A0 NEW:

=A0 =A0 =A0
=A0 =A0 (1) Endpoints in telepresence systems typically have multiple Media= Captures and Media Renderers, e.g., multiple cameras and screens. =A0While= previous system designs were able to set up calls that would capture media= using all cameras and display media on all screens, for example, there is = no mechanism that can associate these Media Captures with each other in spa= ce and time.

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

/*[CNG] */I'd propose a slight reword "Endpoints in telepresence s= ystems typically have multiple Media Capture and Media Render devices, e.g.= , multiple cameras and screens. ..."
[MB2] That s= ounds good to me. [/MB]=A0

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

=A0 =A0 */[Duckworth, Mark] okay/*

/*[CNG] I don't think one paragraph describing this fall back in the fr= amework is too much. I think its helpful to explain fallback behaviour. */<= br>
[MB2] If you read it in the context of that section, i= t doesn't quite seem to fit. It leaves more questions than providing an= swers in my opinion. =A0 It seems to be some leftover text from when the do= cument had a lot more detail - e.g., the text about legacy devices is total= ly unnecessary as they aren't referenced elsewhere in the framework any= longer. =A0I think perhaps the idea of fallback when the device doesn'= t support CLUE can be stated much more concisely. =A0I don't have a pro= posal right off, but will think about it. Unless someone else has suggestio= ns. =A0[/MB2]

=A0 =A0 5) Somewhat General. There was a diagram in Section 5 in the -02 =A0 =A0 version that was dropped in the -03. I really think that more
=A0 =A0 diagrams would help to understand this stuff.

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

=A0 =A0 diagram doesn=92t really say much, but I could try to update it. Th= e
=A0 =A0 one below is a bit much to convert to ASCII./*

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

=A0 =A0 *//*

=A0 =A0 *//*


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


[CNG] ???
[MB2] Sorry, there was another email exchang= e that I hadn't yet sent to the list about making this document standar= ds track and adding some more references. =A0I'll send that now. [/MB2]= =A0
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--001a11c3bed4ae0e7704e50918b4-- From mary.ietf.barnes@gmail.com Wed Aug 28 15:01:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46A821E8054 for ; Wed, 28 Aug 2013 15:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 8S4OTQSboOAe for ; Wed, 28 Aug 2013 15:01:34 -0700 (PDT) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABCD21E8056 for ; Wed, 28 Aug 2013 15:01:19 -0700 (PDT) Received: by mail-qa0-f50.google.com with SMTP id f11so16309qae.16 for ; Wed, 28 Aug 2013 15:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=dHyvV84yWYYf0B8aCbVp+qXNDUGTg2jXhe5K2xeuWSI=; b=n8hCv/nY3JZ+Eunn6t8U8/QVgaqKmEBdzl/6SMPml7gRZKBrZFG7CZ2BwRIfvDlT+3 ZsPfUJ0UfsEBXirTgtkMQo3xAXDT7Bch+iLK9QitZvOZ+wMDCDNYdMBVQ2p2vkgzqNHS dT0FcIH7dT9UjyngCGzZff363C81okPZLr+U6zsHLfz2S8jG8q8WIXY8c443tHVC+kt/ 996C7+ldQGokSu5i4VqzgYRwwzDpIY9v5K7+tZUjMGDAVTs4RhlT096Oy/w0gwhkExdF UfkUf4I+bal/INbJZW7H3Y9vVTORoH3ta8ppLfnJx/DgF8+lNvs4vUcnkGb/vHf9SCzW BFCw== MIME-Version: 1.0 X-Received: by 10.229.224.65 with SMTP id in1mr87330qcb.17.1377727278988; Wed, 28 Aug 2013 15:01:18 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 28 Aug 2013 15:01:18 -0700 (PDT) In-Reply-To: References: <968728441.6671109.1377210816110.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Wed, 28 Aug 2013 17:01:18 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11343e660fc39604e50921b4 Subject: Re: [clue] 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: Wed, 28 Aug 2013 22:01:36 -0000 --001a11343e660fc39604e50921b4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The optimal date & time for the Interim is Tuesday, Sept. 17, 2013 at 8:30-10:30 Central. I'll post the Webex details shortly. Mary. On Thu, Aug 22, 2013 at 5:42 PM, Mary Barnes wrote: > HI all, > > Per discussions at IETF-87, we would like to schedule a virtual interim > meeting before IETF-88. I have setup a doodle poll: > http://doodle.com/sbz67fpa23gfrhca > > Please respond no later than Tuesday, August 27 5pm Central with your > availability, so we can get the meeting on everyone's calendar. While > there has been virtually no mailing list discussion since Berlin, Christian > has submitted the document related to the issue on switched captures: > http://tools.ietf.org/id/draft-groves-clue-multi-content-00.txt > It would be really good for folks to review and comment on that so we can > get that issue resolved. > > Note, that we also discussed restarting the weekly design team meetings, > with the intent of focusing on the solution documents. The time slot we > previously used was 10am Central. If that doesn't work for folks, please > let myself and Paul know ASAP so we can possibly arrange another time. In > particular if it doesn't work for those that volunteered to work on the > solution issues: Simon, Christer H, Paul K, Roberta, Jonathan L, Rob H, > Roni E. > > Thanks, > Mary. > > > --001a11343e660fc39604e50921b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,=A0

The optimal date & time = for the Interim is Tuesday, Sept. 17, 2013 at 8:30-10:30 Central. I'll = post the Webex details shortly.

Mary.=A0


On Thu, Aug 22, 2013 at 5:42 PM, Mary Ba= rnes <mary.ietf.barnes@gmail.com> wrote:
HI all,=A0

Per discussions at IETF-87, = we would like to schedule a virtual interim meeting before IETF-88. =A0I ha= ve setup a doodle poll:
http://doodle.com/sbz67fp= a23gfrhca
=A0
Please respond no later than Tuesday, August 27 5pm Cent= ral with your availability, so we can get the meeting on everyone's cal= endar. =A0While there has been virtually no mailing list discussion since B= erlin, Christian has submitted the document related to the issue on switche= d captures:
It would be really good for folks to r= eview and comment on that so we can get that issue resolved.

Note, that we also discussed restarting the weekl= y design team meetings, with the intent of focusing on the solution documen= ts. =A0The time slot we previously used was 10am Central. =A0 If that doesn= 't work for folks, please let myself and Paul know ASAP so we can possi= bly arrange another time. =A0In particular if it doesn't work for those= that volunteered to work on the solution issues:=A0Simon, Christer H, Pau= l K, Roberta, Jonathan L, Rob H, Roni E.

Thanks,
Mary.


--001a11343e660fc39604e50921b4-- From mary.ietf.barnes@gmail.com Wed Aug 28 15:10:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B010921F9B6A for ; Wed, 28 Aug 2013 15:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=1.228, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 Czx9MDPsielG for ; Wed, 28 Aug 2013 15:10:01 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 41D2511E81D7 for ; Wed, 28 Aug 2013 15:09:59 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id cm18so772862qab.1 for ; Wed, 28 Aug 2013 15:09:58 -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=5XDyLokCNnSJKCUkWJiTw/o/vwz6hEifKyYQ1Xa78ek=; b=su59P7bBmwcUeXI1DBp5roPi15K3cPTMwBJIuFFTplPw7lDb0ar3Y9gcUyvV62i5Zj GStTy7a9HpmxpZmUQJjLkTNlZlWPX85IEz7F07aSvTUJeqwU50Ha8YLeRm0MDlPzs1WL qFZmYXuUpmYaF8OgWALzoWjEVPov7CNT9CtmRPYuJLONAE36lXxs7BV3zAr87F7RacsL tMXUE6pRmwiwiEHNLjcpBBKADpctom8JJ8f5TNk1Q7Wedet0fN3YFbG0USXS2VEgGqPB LfQ6Pdoux6M57QKRDoHZMWN5I5wDPCcHVv+uFzfDgf2w6flSoK1Ufb0WVi3gnjrmZL6z 0m6g== MIME-Version: 1.0 X-Received: by 10.49.81.196 with SMTP id c4mr108022qey.35.1377727798333; Wed, 28 Aug 2013 15:09:58 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 28 Aug 2013 15:09:58 -0700 (PDT) Date: Wed, 28 Aug 2013 17:09:58 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b6d96540473a704e5094071 Subject: [clue] Meeting invitation: CLUE WG Virtual Interim, Sept. 17, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:10:02 -0000 --047d7b6d96540473a704e5094071 Content-Type: text/plain; charset=ISO-8859-1 Below please find the details for the Webex for the interim meeting. A rough agenda is available on the wiki and will be updated before the meeting based upon documents submitted and WG activity up to the meeting: http://trac.tools.ietf.org/wg/clue/trac/wiki Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Wed, Aug 28, 2013 at 5:04 PM Subject: Meeting invitation: CLUE WG Virtual Interim To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Virtual Interim Date: Tuesday, September 17, 2013 Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 640 958 986 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=233806742&UID=1625952727&PW=NOWJmYzgxMmQw&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=233806742&UID=1625952727&PW=NOWJmYzgxMmQw&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:640 958 986 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=233806742&UID=1625952727&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAmey-u8xCcGnO10B/YAAm6ayMp9PDgHUMVIhS1o9hclu&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x640958986# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --047d7b6d96540473a704e5094071 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Below please find the details for the Webex for the interi= m meeting. =A0A rough agenda is available on the wiki and will be updated b= efore the meeting based upon
documents submitted and WG activity up to = the meeting:

Regards,
=
Mary.

---------- Forwarded message -= ---------
From: Clue Working Group <messenger@webex.com>
Date: Wed, Aug 28, 2013 at 5:04 PM
Subject: Meeting invitation: = CLUE WG Virtual Interim
To: mary.ietf.barnes@gmail.co= m


https://ietf.webex.com/ietf/j.php= ?ED=3D233806742&UID=3D1625952727&PW=3DNOWJmYzgxMmQw&RT=3DMiM3
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://iet= f.webex.com/ietf/j.php?ED=3D233806742&UID=3D1625952727&PW=3DNOWJmYz= gxMmQw&ORT=3DMiM3

-------------------------------------------------------
To join = the audio conference only
--------------------------------------------= -----------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:640 958 986

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
clue-chairs@tools.ietf.org


To add this meeti= ng to your calendar program (for example Microsoft Outlook), click this lin= k:
http= s://ietf.webex.com/ietf/j.php?ED=3D233806742&UID=3D1625952727&ICS= =3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAmey-u8xCcGnO10B/YAAm= 6ayMp9PDgHUMVIhS1o9hclu&RT=3DMiM3

The playback of UCF (Universal Communications Format) rich media file= s requires appropriate players. To view this type of rich media files in th= e meeting, please check whether you have the players installed on your comp= uter by going to https://ietf.webex.com/ietf/systemdiagnosis.php.
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+16504793208x640958986#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.

--047d7b6d96540473a704e5094071-- From mary.ietf.barnes@gmail.com Wed Aug 28 15:24:25 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 C061621F9A7D for ; Wed, 28 Aug 2013 15:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4BVgMp35UZ6 for ; Wed, 28 Aug 2013 15:24:25 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 27E0921F99B8 for ; Wed, 28 Aug 2013 15:24:25 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so3839784qen.34 for ; Wed, 28 Aug 2013 15:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iUKWRd+lX2MORvGhXTluHlTEWsyaPwEttWdpAuFr0to=; b=eK2EH6rqrO7/GXxJzkD+ScKpXO1k3SlnDPNIvVqpVB41k+k8RQ4od5Xvoq61BulGVs cwTPJo4Cx5EJWgWNsKYpI/90dlPT709Cq514NqNAPkWtkgfKl0fet1tmeifpPdusxLRh VzkKEJ//xCzsvR4V6KmKbudaUismXVvc9853MhhgmnpFBS01Acf0rKZY5sfIzYFpr6fq TLKqRvC6xWAk0MD7kRho4ZBBYcLpLdGP89Wh565mROWgihUSMY/lOV1BcDTbf9HYa18U /jGvSV2/XdmOaVtAFvEfxamYKzmZ/To+7sP/AfMJqd57yZhgrPZAfJeUKHH6isDikjWx kPnQ== MIME-Version: 1.0 X-Received: by 10.224.6.9 with SMTP id 9mr1044231qax.41.1377728664683; Wed, 28 Aug 2013 15:24:24 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Wed, 28 Aug 2013 15:24:24 -0700 (PDT) Date: Wed, 28 Aug 2013 17:24:24 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c2cbf2a7cb6304e5097376 Subject: [clue] CLUE Framework comments and general thoughts on organization of other 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: Wed, 28 Aug 2013 22:24:25 -0000 --001a11c2cbf2a7cb6304e5097376 Content-Type: text/plain; charset=ISO-8859-1 Here is another more general set of comments on the framework document. Putting together text for the security requirements section for the framework has made me consider how we have the documents structured and the dependencies. 1) The CLUE Framework document needs to be standards track (it's already a normative reference in the signaling document) as it outlines normative implementation details. So, the document needs to be revised to ensure that "must"s are "MUST"s and some text may need to be changed to be normative - e.g., "can be" -> MAY, etc. 2) As we've discussed we probably will not publish the Framework until the other detailed solution documents are near completion. [Although, it is not a problem to have informative references as works in progress.] So, I think that the framework document should be more explicit about referencing the solution documents. One reason I think this is that some of the details are very specific (e.g., the use of the names of specific data elements). Also, it has been a while since I've carefully reviewed the framework from start to finish and it seems to me that it leaves you hanging without having references to where all the details are found. Adding that will also make it easier to reference specifics in the security analysis and be able to re-assure the security folks that the issues are addressed in the other solution documents. Thus, I think the framework would be a good document to outline the solution documents (e.g., there is already an indirect reference to the RTP document). Thanks, Mary. --001a11c2cbf2a7cb6304e5097376 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here is another more general set of comments on the framew= ork document.

Putting t= ogether text for the security requirements section for the framework has ma= de me consider how we have the documents structured and the dependencies. = =A0

1) The CLUE Framework document needs to be standards track (= it's already a normative reference in the signaling document) as it out= lines normative implementation details. =A0So, the document needs to be rev= ised to ensure that "must"s are "MUST"s and some text m= ay need to be changed to be normative - e.g., "can be" -> MAY,= etc. =A0=A0

2) As we've discussed we probably = will not publish the Framework until the other detailed solution documents = are near completion. =A0[Although, it is not a problem to have informative = references as works in progress.] =A0=A0So, I =A0think that the framework d= ocument should be more explicit about referencing the solution documents. = =A0One reason I think this is that some of the details are very specific (e= .g., the use of the names of specific data elements). =A0Also, it has been = a while since I've carefully reviewed the framework from start to finis= h and it seems to me that it leaves you hanging without having references t= o where all the details are found.=A0Adding that will also make it e= asier to reference specifics in the security analysis and be able to re-ass= ure the security folks that the issues are addressed in the other solution = documents.=A0Thus,=A0I think the framework would be a good= document to outline the solution documents (e.g., there is already an indi= rect reference to the RTP document).=A0

Thanks,=
Mary.=A0



--001a11c2cbf2a7cb6304e5097376-- From keith.drage@alcatel-lucent.com Thu Aug 29 04:13: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 DDFA121F9DDB for ; Thu, 29 Aug 2013 04:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.608 X-Spam-Level: X-Spam-Status: No, score=-110.608 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M0XjKTORTsp for ; Thu, 29 Aug 2013 04:13:19 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4621F9DC6 for ; Thu, 29 Aug 2013 04:13:19 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r7TBDFbP029705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 29 Aug 2013 06:13:17 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r7TBDE25027971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Aug 2013 13:13:15 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 29 Aug 2013 13:13:14 +0200 From: "DRAGE, Keith (Keith)" To: CLUE Thread-Topic: [clue] CLUE Framework comments and general thoughts on organization of other documents Thread-Index: AQHOpEfPg9ptJYnjfU200fDNwkmXAJmrUL1AgAC39OA= Date: Thu, 29 Aug 2013 11:13:13 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B08ABC8@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B08ABC8FR712WXCHMBA11zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: [clue] FW: CLUE Framework comments and general thoughts on organization of other 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: Thu, 29 Aug 2013 11:13:25 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B08ABC8FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This apparently disappeared in the mailing list glitch last night. Keith ________________________________ From: DRAGE, Keith (Keith) Sent: 29 August 2013 01:17 To: 'Mary Barnes' Cc: CLUE Subject: RE: [clue] CLUE Framework comments and general thoughts on organiz= ation of other documents I did not say there were none. I said that I had quickly gone through the d= ocument and detected at least one example of each of the items I identified= . Therefore it is not a case of replacing all "must" with "MUST" which is w= hat one reading of your comment could infer. But for the paragraph you quoted, why are these requirements not in the sig= nalling document? Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 29 August 2013 00:39 To: DRAGE, Keith (Keith) Cc: CLUE Subject: Re: [clue] CLUE Framework comments and general thoughts on organiz= ation of other documents You might want to read the document from start to finish more closely (I ca= n't fathom you could have done that between the time I sent the email and y= ou responded). Here is one example that clearly has normative content (6.= 2.2): In the provider's Advertisement, this attribute can have multiple values, which means the provider supports each of the indicated policies. The consumer, when it requests media captures from this Capture Scene Entry, should also include this attribute but with only the single value (from among the values indicated by the provider) indicating the Consumer's choice for which policy it wants the provider to use. The Consumer must choose the same value for all the Media Captures in the Capture Scene Entry. If the provider does not support any of these policies, it should omit this attribute. My suggestion is that the above be reworded something like: In the provider's Advertisement, this attribute MAY have multiple values, which means the provider supports each of the indicated policies. The consumer, when it requests media captures from this Capture Scene Entry, SHOULD also include this attribute but with only the single value (from among the values indicated by the provider) indicating the Consumer's choice for which policy it wants the provider to use. The Consumer MUST choose the same value for all the Media Captures in the Capture Scene Entry. If the provider does not support any of these policies, it SHOULD omit this attribute. I don't expect there would be a lot of these, but these are key to the CLUE= model and if the solution doesn't follow those, then we've wasted a lot of= time on this document. Also, we have done this for previous documents that have followed a similar= model - e.g., XCON Framework. That was originally targeted as PS (in the = chartered deliverables), but the WG decided at one point that it thought it= should be informational, so we changed it: http://www.ietf.org/mail-archive/web/xcon/current/msg01974.html We ended up changing it back during IETF Last call: http://www.ietf.org/mail-archive/web/gen-art/current/msg02327.html Mary. On Wed, Aug 28, 2013 at 6:07 PM, DRAGE, Keith (Keith) > wrote: On 1) I don't think it is as simple as this. Firstly, I am not really sure why it is a normative reference from the sign= alling document. Which particular reference from that document are you thin= king is the normative one. Yes, I know it is listed in the normative refere= nces, but references only have impact when they are quoted from the main te= xt. Secondly, I did a quick scan of the "must"s in the framework document and f= ound at least examples that: - still need to be informative because they are part o= f descriptive text (we should probably reword) - duplicate requirements that are probably elsewhere e= .g. in the signalling document, and we should not double specify - are statements about what other documents are meant = to contain, rather than requirements on the implementation None of these in my view should be upper case "MUST". Regards Keith ________________________________ From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: 28 August 2013 23:24 To: CLUE Subject: [clue] CLUE Framework comments and general thoughts on organizatio= n of other documents Here is another more general set of comments on the framework document. Putting together text for the security requirements section for the framewo= rk has made me consider how we have the documents structured and the depend= encies. 1) The CLUE Framework document needs to be standards track (it's already a = normative reference in the signaling document) as it outlines normative imp= lementation details. So, the document needs to be revised to ensure that "= must"s are "MUST"s and some text may need to be changed to be normative - e= .g., "can be" -> MAY, etc. 2) As we've discussed we probably will not publish the Framework until the = other detailed solution documents are near completion. [Although, it is no= t a problem to have informative references as works in progress.] So, I = think that the framework document should be more explicit about referencing= the solution documents. One reason I think this is that some of the detai= ls are very specific (e.g., the use of the names of specific data elements)= . Also, it has been a while since I've carefully reviewed the framework fr= om start to finish and it seems to me that it leaves you hanging without ha= ving references to where all the details are found. Adding that will also m= ake it easier to reference specifics in the security analysis and be able t= o re-assure the security folks that the issues are addressed in the other s= olution documents. Thus, I think the framework would be a good document to = outline the solution documents (e.g., there is already an indirect referenc= e to the RTP document). Thanks, Mary. --_000_949EF20990823C4C85C18D59AA11AD8B08ABC8FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This apparently disappeared in the mai= ling list glitch last night.

 

Keith

 

From: DRAGE, Keith (Keith)
Sent: 29 August 2013 01:17 To: 'Mary Barnes'
Cc: CLUE
Subject: RE: [clue] CLUE Fra= mework comments and general thoughts on organization of other documents

 

I did not say there were none. I said = that I had quickly gone through the document and detected at least one exam= ple of each of the items I identified. Therefore it is not a case of replacing all “must̶= 1; with “MUST” which is what one reading of your comment could = infer.

 

But for the paragraph you quoted, why = are these requirements not in the signalling document?

 

Keith

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 29 August 2013 00:39 To: DRAGE, Keith (Keith)
Cc: CLUE
Subject: Re: [clue] CLUE Fra= mework comments and general thoughts on organization of other documents

 

You might want to read the document from start to finish more close= ly (I can't fathom you could have done that between the time I sent the ema= il and you responded).   Here is one example that clearly has normative content (6.2.2):

   In the
   provider's Advertisement, this at=
tribute can have multiple values,
   which means the provider supports=
 each of the indicated policies.
   The consumer, when it requests me=
dia captures from this Capture
   Scene Entry, should also include =
this attribute but with only the
   single value (from among the valu=
es indicated by the provider)
   indicating the Consumer's choice =
for which policy it wants the
   provider to use.  The Consum=
er must choose the same value for all
   the Media Captures in the Capture=
 Scene Entry.  If the provider
   does not support any of these pol=
icies, it should omit this
   attribute.

 

My suggestion is that the above be reworded something like:

 
   In the

   provider's Advertisement, this at=
tribute MAY have multiple va=
lues,


   which means the provider supports=
 each of the indicated policies.


   The consumer, when it requests me=
dia captures from this Capture


   Scene Entry, SHOULD also include =
this attribute but with only the


   single value (from among the valu=
es indicated by the provider)


   indicating the Consumer's choice =
for which policy it wants the


   provider to use.  The Consum=
er MUST choose the same value for all


   the Media Captures in the Capture=
 Scene Entry.  If the provider


   does not support any of these pol=
icies, it SHOULD omit this


   attribute.




 

I don't expect there would be a lot of these, but these are key to = the CLUE model and if the solution doesn't follow those, then we've wasted = a lot of time on this document.  

 

Also, we have done this for previous documents that have followed a= similar model - e.g., XCON Framework.  That was originally targeted a= s PS (in the chartered deliverables), but the WG decided at one point that it thought it should be informational= , so we changed it:

 

We ended up changing it back during IETF Last call:

 

Mary.

 

On Wed, Aug= 28, 2013 at 6:07 PM, DRAGE, = Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:=

On 1) I don’t think it is as simple as this.

 

Firstly, I am not really sure why it is a normative reference f= rom the signalling document. Which particular reference from that document are you thinking i= s the normative one. Yes, I know it is listed in the normative references, = but references only have impact when they are quoted from the main text.

 

Secondly, I did a quick scan of the “must”s in the = framework document and found at least examples that:

-   &nbs= p;            &= nbsp;     still need to be informative because they are= part of descriptive text (we should probably reword)

-   &nbs= p;            &= nbsp;     duplicate requirements that are probably else= where e.g. in the signalling document, and we should not double specify

-   &nbs= p;            &= nbsp;     are statements about what other documents are= meant to contain, rather than requirements on the implementation

None of these in my view should be upper case “MUST”= ;.

 

Regards

 

Keith

 

From:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:Tahoma"> clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 28 August 2013 23:24 To: CLUE
Subject: [clue] CLUE Framewo= rk comments and general thoughts on organization of other documents<= /font>

 

Here is another more general set of comments on the framework docu= ment.

 

Putting together text for the security requirements section for th= e framework has made me consider how we have the documents structured and the dependencies.  

 

1) The CLUE Framework document needs to be standards track (it's a= lready a normative reference in the signaling document) as it outlines normative implementation details.  So, the d= ocument needs to be revised to ensure that "must"s are "MUST= "s and some text may need to be changed to be normative - e.g., "= can be" -> MAY, etc.   <= /o:p>

 

2) As we've discussed we probably will not publish the Framework u= ntil the other detailed solution documents are near completion.  [Although, it is not a problem to have informat= ive references as works in progress.]   So, I  think that th= e framework document should be more explicit about referencing the solution= documents.  One reason I think this is that some of the details are very specific (e.g., the use of the names of specific data= elements).  Also, it has been a while since I've carefully reviewed t= he framework from start to finish and it seems to me that it leaves you han= ging without having references to where all the details are found. Adding that will also make it easier to re= ference specifics in the security analysis and be able to re-assure the sec= urity folks that the issues are addressed in the other solution documents.&= nbsp;Thus, I think the framework would be a good document to outline the solution documents (e.g., there is already = an indirect reference to the RTP document). 

 

Thanks,

Mary. 

 

 

 

 

--_000_949EF20990823C4C85C18D59AA11AD8B08ABC8FR712WXCHMBA11zeu_-- From mary.ietf.barnes@gmail.com Thu Aug 29 06:01:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34FD21F9B07 for ; Thu, 29 Aug 2013 06:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZN2b7g4kz-2 for ; Thu, 29 Aug 2013 06:01:54 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEB21F9BFA for ; Thu, 29 Aug 2013 06:01:26 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id en1so435604wid.17 for ; Thu, 29 Aug 2013 06:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BK2/IuHY0M3dfN4KxARtuVH3AUu9OTPE0WvumXInnAg=; b=SNpWwe0jOw6Ztftkqz93nd0ulS+9HSgaAzU1u3vsX41mrZTnJ7vJPbiwIIbYNRrRwh 05VadVA5YzZIDzsc8vQ2Py2plGg2cOHBNeyZ61Kuuz7oIwqXlRioKaLuUvsGMWwqt2wW i0mO47E3YALhCRMLPkI95FFCN80Fet533g21xVONlMnqz5EOLtI3m0PalONVr65veVam q8VoUIsASvoBVtPvBKLtDdr2ZHY6tgaxwqyofccJ7j8CTtapTa7QocwWo2QjnOH8sjJk D9rGHcei1OAUFxWSJYQi6jnvx6WeDkoCoIG5BPvXwlaAvw9mO8xklFwMo/Ft9OAupZFv Zxtw== MIME-Version: 1.0 X-Received: by 10.194.87.36 with SMTP id u4mr5094257wjz.64.1377781278879; Thu, 29 Aug 2013 06:01:18 -0700 (PDT) Received: by 10.216.36.69 with HTTP; Thu, 29 Aug 2013 06:01:18 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B08A878@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <949EF20990823C4C85C18D59AA11AD8B08A819@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B08A878@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 29 Aug 2013 08:01:18 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e0102dee8b4b5e104e515b3e6 Cc: CLUE Subject: Re: [clue] CLUE Framework comments and general thoughts on organization of other 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: Thu, 29 Aug 2013 13:01:56 -0000 --089e0102dee8b4b5e104e515b3e6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Aug 28, 2013 at 7:16 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > ****** > > I did not say there were none. I said that I had quickly gone through the > document and detected at least one example of each of the items I > identified. Therefore it is not a case of replacing all =93must=94 with = =93MUST=94 > which is what one reading of your comment could infer. > [MB] I did not say that the task was a merely a global change of "must" to "MUST" The etc. implies that you do what is sensible. As usual, each occurrence needs to be reviewed and a decision made as to whether there is a normative state there. FYI, this is some text I sent to Mark as he did ask for clarification on that and maybe this will help you understand better: .... I think you can make a first (and probably fairly accurate pass) by searching on the lower case versions of the words and IF they are stating something normative, changing them to all CAPs. Folks debate as to whether alternative words should be used if the text isn't really stating anything normative - e.g., should -> ought, may-> can, etc. Related to this, you should revisit the "cans" to see if they ought to be MAYs. I am a bit OCD about this, but it doesn't have to be perfect as long as the basic normative stuff is at least highlighted..... [/MB] > ** > > But for the paragraph you quoted, why are these requirements not in the > signalling document? > [MB] Those requirements absolutely should be reflected in the solution document, but will be much more specific, referring to specific messages carrying the data and would likely occur in a different context. The framework is a higher level description of the messaging and information required to support the CLUE functionality. The data model and signaling are the realization of the framework and are what will ensure interoperability on the wire. BTW, if you think this text isn't needed in the FW, please feel free to suggest where this text should be moved into the signaling solution document. [/MB] > Keith**** > > ** ** > ------------------------------ > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 29 August 2013 00:39 > *To:* DRAGE, Keith (Keith) > *Cc:* CLUE > *Subject:* Re: [clue] CLUE Framework comments and general thoughts on > organization of other documents**** > > ** ** > > You might want to read the document from start to finish more closely (I > can't fathom you could have done that between the time I sent the email a= nd > you responded). Here is one example that clearly has normative content > (6.2.2):**** > > In the**** > > provider's Advertisement, this attribute can have multiple values,**** > > which means the provider supports each of the indicated policies.**** > > The consumer, when it requests media captures from this Capture**** > > Scene Entry, should also include this attribute but with only the**** > > single value (from among the values indicated by the provider)**** > > indicating the Consumer's choice for which policy it wants the**** > > provider to use. The Consumer must choose the same value for all**** > > the Media Captures in the Capture Scene Entry. If the provider**** > > does not support any of these policies, it should omit this**** > > attribute.**** > > ** ** > > My suggestion is that the above be reworded something like:**** > > ** ** > > In the**** > > provider's Advertisement, this attribute **MAY** have multiple values,= **** > > which means the provider supports each of the indicated policies.**** > > The consumer, when it requests media captures from this Capture**** > > Scene Entry, SHOULD also include this attribute but with only the**** > > single value (from among the values indicated by the provider)**** > > indicating the Consumer's choice for which policy it wants the**** > > provider to use. The Consumer MUST choose the same value for all**** > > the Media Captures in the Capture Scene Entry. If the provider**** > > does not support any of these policies, it SHOULD omit this**** > > attribute.**** > > ** ** > > I don't expect there would be a lot of these, but these are key to the > CLUE model and if the solution doesn't follow those, then we've wasted a > lot of time on this document. **** > > ** ** > > Also, we have done this for previous documents that have followed a > similar model - e.g., XCON Framework. That was originally targeted as PS > (in the chartered deliverables), but the WG decided at one point that it > thought it should be informational, so we changed it:**** > > http://www.ietf.org/mail-archive/web/xcon/current/msg01974.html**** > > ** ** > > We ended up changing it back during IETF Last call:**** > > http://www.ietf.org/mail-archive/web/gen-art/current/msg02327.html**** > > ** ** > > Mary.**** > > ** ** > > On Wed, **Aug 28, 2013** at **6:07 PM**, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote:**** > > On 1) I don=92t think it is as simple as this.**** > > **** > > Firstly, I am not really sure why it is a normative reference from the > signalling document. Which particular reference from that document are yo= u > thinking is the normative one. Yes, I know it is listed in the normative > references, but references only have impact when they are quoted from the > main text.**** > > **** > > Secondly, I did a quick scan of the =93must=94s in the framework document= and > found at least examples that:**** > > - still need to be informative because they are part > of descriptive text (we should probably reword)**** > > - duplicate requirements that are probably elsewhere > e.g. in the signalling document, and we should not double specify**** > > - are statements about what other documents are > meant to contain, rather than requirements on the implementation**** > > None of these in my view should be upper case =93MUST=94.**** > > **** > > Regards**** > > **** > > Keith**** > > **** > ------------------------------ > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 28 August 2013 23:24 > *To:* CLUE > *Subject:* [clue] CLUE Framework comments and general thoughts on > organization of other documents**** > > **** > > Here is another more general set of comments on the framework document.**= * > * > > **** > > Putting together text for the security requirements section for the > framework has made me consider how we have the documents structured and t= he > dependencies. **** > > **** > > 1) The CLUE Framework document needs to be standards track (it's already = a > normative reference in the signaling document) as it outlines normative > implementation details. So, the document needs to be revised to ensure > that "must"s are "MUST"s and some text may need to be changed to be > normative - e.g., "can be" -> **MAY**, etc. **** > > **** > > 2) As we've discussed we probably will not publish the Framework until th= e > other detailed solution documents are near completion. [Although, it is > not a problem to have informative references as works in progress.] So,= I > think that the framework document should be more explicit about > referencing the solution documents. One reason I think this is that some > of the details are very specific (e.g., the use of the names of specific > data elements). Also, it has been a while since I've carefully reviewed > the framework from start to finish and it seems to me that it leaves you > hanging without having references to where all the details are > found. Adding that will also make it easier to reference specifics in the > security analysis and be able to re-assure the security folks that the > issues are addressed in the other solution documents. Thus, I think the > framework would be a good document to outline the solution documents (e.g= ., > there is already an indirect reference to the **RTP** document). **** > > **** > > Thanks,**** > > Mary. **** > > **** > > **** > > **** > > ** ** > --089e0102dee8b4b5e104e515b3e6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 28, 2013 at 7:16 PM, DRAGE, Keith (Keith) <ke= ith.drage@alcatel-lucent.com> wrote:

I did not say there were none. I said th= at I had quickly gone through the document and detected at least one exampl= e of each of the items I identified. Therefore it is not a case of replacing all =93must=94 with = =93MUST=94 which is what one reading of your comment could infer.

[MB] I did not say that the task was = a merely a global change of "must" to "MUST" =A0 The et= c. implies that you do what is sensible. =A0As usual, each occurrence needs= to be reviewed and a decision made as to whether there is a normative stat= e there. =A0FYI, this is some text I sent to Mark as he did ask for clarifi= cation on that and maybe this will help you understand better:

.... I think you can make a first = (and probably fairly accurate pass) by searching on the lower case versions= of the words and IF they are stating something normative, changing them to= all CAPs. =A0Folks debate as to whether alternative words should be used i= f the text isn't really stating anything normative - e.g., should ->= ought, may-> can, etc. =A0Related to this, you should revisit the "= ;cans" to see if they ought to be MAYs. =A0I am a bit OCD about this, = but it doesn't have to be perfect as long as the basic normative stuff = is at least highlighted.....

[/MB]

=A0

But for the paragraph you quoted, why ar= e these requirements not in the signalling document?

[MB] =A0Those requirements absolutely should be reflected= in the solution document, but will be much more specific, referring to spe= cific messages carrying the data and would likely occur in a different cont= ext. =A0The framework is a higher level description of the messaging and in= formation required to support the CLUE functionality. The data model and signaling are the realization of the framewor= k and are what will ensure interoperability on the wire. =A0

BTW, if you think this = text isn't needed in the FW, please feel free to suggest where this tex= t should be moved into the signaling solution document. [/MB]

Keith

=A0

From: Mary Barnes [mailto:ma= ry.ietf.barnes@gmail.com]
Sent: 29 August 2013 00:39 To: DRAGE, Keith (Keith)
Cc: CLUE
Subject: Re: [clue] CLUE Fra= mework comments and general thoughts on organization of other documents

=A0

You might want to read the document from start to finish more c= losely (I can't fathom you could have done that between the time I sent= the email and you responded). =A0 Here is one example that clearly has normative content (6.2.2):= 

=A0=A0 In the
=A0=A0 provider's Advertisement, this attribute can have multiple v=
alues,
=A0=A0 which means the provider supports each of the indicated policies=
.
=A0=A0 The consumer, when it requests media captures from this Capture<=
u>
=A0=A0 Scene Entry, should also include this attribute but with only th=
e
=A0=A0 single value (from among the values indicated by the provider)
=A0=A0 indicating the Consumer's choice for which policy it wants t=
he
=A0=A0 provider to use.=A0 The Consumer must choose the same value for =
all
=A0=A0 the Media Captures in the Capture Scene Entry.=A0 If the provide=
r
=A0=A0 does not support any of these policies, it should omit this
=A0=A0 attribute.

=A0

My suggestion is that the above be reworded something like:<= /u>

=A0
=A0=A0 In the
=A0=A0 provider's Advertisement, this attribute MAY h=
ave multiple values,
=A0=A0 which means the provider supports each of the indicated policies=
.
=A0=A0 The consumer, when it requests media captures from this Capture<=
u>
=A0=A0 Scene Entry, SHOULD also include this attribute but with only th=
e
=A0=A0 single value (from among the values indicated by the provider)
=A0=A0 indicating the Consumer's choice for which policy it wants t=
he
=A0=A0 provider to use.=A0 The Consumer MUST choose the same value for =
all
=A0=A0 the Media Captures in the Capture Scene Entry.=A0 If the provide=
r
=A0=A0 does not support any of these policies, it SHOULD omit this
=A0=A0 attribute.

=A0

I don't expect there would be a lot of these, but these are= key to the CLUE model and if the solution doesn't follow those, then w= e've wasted a lot of time on this document. =A0

=A0

Also, we have done this for previous documents that have follow= ed a similar model - e.g., XCON Framework. =A0That was originally targeted = as PS (in the chartered deliverables), but the WG decided at one point that it thought it should be informational= , so we changed it:

=A0

We ended up changing it back during IETF Last call:

=A0

Mary.

=A0

On Wed, Aug 28, 2013 at 6:07 PM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:

On 1) I don=92t think it is as simple as= this.

=A0

Firstly, I am not really sure why it is = a normative reference from the signalling document. Which particular reference from that document are you thinking i= s the normative one. Yes, I know it is listed in the normative references, = but references only have impact when they are quoted from the main text.

=A0

Secondly, I did a quick scan of the =93m= ust=94s in the framework document and found at least examples that:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 still need to be informative because the= y are part of descriptive text (we should probably reword)=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 duplicate requirements that are probably= elsewhere e.g. in the signalling document, and we should not double specif= y

-=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 are statements about what other document= s are meant to contain, rather than requirements on the implementation

None of these in my view should be upper= case =93MUST=94.

=A0

Regards

=A0

Keith

=A0

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 28 August 2013 23:24 To: CLUE
Subject: [clue] CLUE Framewo= rk comments and general thoughts on organization of other documents<= /font>

=A0

Here is another more general set of comments on the framework d= ocument.

=A0

Putting together text for the security requirements section for= the framework has made me consider how we have the documents structured and the dependencies. =A0

=A0

1) The CLUE Framework document needs to be standards track (it&= #39;s already a normative reference in the signaling document) as it outlines normative implementation details. =A0So, the docu= ment needs to be revised to ensure that "must"s are "MUST&qu= ot;s and some text may need to be changed to be normative - e.g., "can= be" -> MAY, etc. =A0=A0

=A0

2) As we've discussed we probably will not publish the Fram= ework until the other detailed solution documents are near completion. =A0[Although, it is not a problem to have informative= references as works in progress.] =A0=A0So, I =A0think that the framework = document should be more explicit about referencing the solution documents. = =A0One reason I think this is that some of the details are very specific (e.g., the use of the names of specific data= elements). =A0Also, it has been a while since I've carefully reviewed = the framework from start to finish and it seems to me that it leaves you ha= nging without having references to where all the details are found.=A0Adding that will also make it easier to refer= ence specifics in the security analysis and be able to re-assure the securi= ty folks that the issues are addressed in the other solution documents.=A0T= hus,=A0I think the framework would be a good document to outline the solution documents (e.g., there is already = an indirect reference to the RTP document).=A0

=A0

Thanks,

Mary.=A0

=A0

=A0

=A0

=A0


--089e0102dee8b4b5e104e515b3e6-- From mary.ietf.barnes@gmail.com Thu Aug 29 08:01: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 8F14121F81FF for ; Thu, 29 Aug 2013 08:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHX6Z0i+Izmk for ; Thu, 29 Aug 2013 08:01:18 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B121E8082 for ; Thu, 29 Aug 2013 08:00:45 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so258507qen.6 for ; Thu, 29 Aug 2013 08:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ldz37LfficzjEpEt6Cj29RKTjQ0T864/zWhXbpvgLhk=; b=i0+mwG1zm+frLBz9cXZ49ZGlcuilirXFIw3IE1iYqjteQeuJDdPmfD4Y8VDanniArc exvn5oHD9nUWuJ6RtdaNCJzEeeek59yTvwAGKbClPhMdAwg8lmC/d7SykMjleofchcka q3TDeb3syrXizmWHdLW31YN+z5vt2NaD/T7KH8VFWslf24Lx6Js3S8ITSTAM5IuiUglZ m8DtB2o2Mw11Wq+q/swhlFbwDmI/Iw8O3JfkvuzjOaSxDWArCN3VQwloPEz6xxO4qB4W cBDDE+RKQ9jekqtK2FfAmuou3U/AyZdf+dzr8CdVTRgMgfTGdJv5e61VMcxeM+k6EJ+c pNYw== MIME-Version: 1.0 X-Received: by 10.49.62.3 with SMTP id u3mr4458616qer.6.1377788435107; Thu, 29 Aug 2013 08:00:35 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Thu, 29 Aug 2013 08:00:35 -0700 (PDT) In-Reply-To: <521E8C8F.7000603@nteczone.com> References: <49E45C59CA48264997FEBFB29B6BC2D602A2C00F@CRPMBOXPRD07.polycom.com> <521D7313.6030609@nteczone.com> <521E8C8F.7000603@nteczone.com> Date: Thu, 29 Aug 2013 10:00:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7bdc15ac40153704e5175e98 Subject: [clue] Fwd: Fwd: Comments on CLUE Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:01:20 -0000 --047d7bdc15ac40153704e5175e98 Content-Type: text/plain; charset=ISO-8859-1 I apologize if this is a duplicate, but I don't see this in the archives. We got an email from the AMS guys this morning and there was email lost yesterday between 3.30pm PST and 8.55pm PST. So, I'm thinking this was one of them. Mary. ---------- Forwarded message ---------- From: Christian Groves Date: Wed, Aug 28, 2013 at 6:49 PM Subject: Re: [clue] Fwd: Comments on CLUE Framework To: Mary Barnes Cc: CLUE Hello Mary, Please see my reply below. Regards, Christian ..snip.. > > 3) The fact that SIP and SDP offer/answer are used for basic > session setup as well as when needed during the session (as > described in detail in solution documents) isn't > highlighted early > enough or often enough. Given we've had lots of folks > thinking we > were trying to invent something new entirely, I think it's > really > important for this be quite explicit early on. I think this > relates to additional text that should be in the > introduction. I > think something like the following will be sufficient: > > NEW: > > This document identifies the protocols necessary to > achieve the > functionality per the use cases and requirements. The basic > session setup for the use cases is based on SIP [RFC 3261] > and SDP > offer/answer [RFC 3264]. The details with regards to this > signaling are provided in the solution documents. In > addition to > basic SIP & SDP offer/answer, CLUE specific signaling is > required > to exchange the information describing the multiple media > streams. > The details of this signaling and the information required > to be > exchanged is described in subsequent sections of this > document. > > */[Duckworth, Mark] sounds good. We tried to say this > about using > > SDP O/A, but not until the end of section 4. It does seem > better > to say it earlier./* > > /*[CNG] I think we should also make it clear that whilst "SIP and > SDP O/A" are mainly discussed it does not prevent CLUE from being > used in networks where there are other call controls i.e. H.32x, > WebRTC, what ever the future holds.... */ > > [MB2] I don't disagree with what you say but I don't think we should say > anything about that given our charter, which limits the work to SIP. That's > opening up the question as to how that will work, whether additional > specification is required,etc. [/MB2] > > > [CNG] I appreciate CLUE is chartered to specify how CLUE works with SIP. I don't think anyone wants to preclude the widespread use of CLUE so I think it is worthwhile to specify that CLUE can only be used with SIP. If its a question of addition specification etc. I think we can simply some text saying that we're not working on them: e.g. "Whilst "SIP and SDP O/A" are discussed it does not prevent CLUE from being used in networks where there are other call controls however the use of these is not considered nor described by the framework." --047d7bdc15ac40153704e5175e98 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I apologize if this is a duplicate, but I don't see th= is in the archives. =A0We got an email from the AMS guys this morning and t= here was email lost yesterday between=A03.30pm PST an= d 8.55pm PST. So, I'm thinking this was one of them.

Mary.=A0

---------- Forwar= ded message ----------
From: Christian Gro= ves <Christian.Groves@nteczone.com>
Date: Wed, Aug 28, 2013 at 6:49 PM
Subject: Re: [clue] Fwd: Comments on = CLUE Framework
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Cc: CLUE &= lt;clue@ietf.org>=


Hello Mary,

Please see my reply below.

Regards, Christian
..snip..



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

=A0 =A0 =A0 =A0 =A0 =A0 NEW:

=A0 =A0 =A0 =A0 =A0 =A0 This document identifies the protocols necessary to=
=A0 =A0 =A0 =A0 achieve the
=A0 =A0 =A0 =A0 =A0 =A0 functionality per the use cases and requirements. T= he basic
=A0 =A0 =A0 =A0 =A0 =A0 session setup for the use cases is based on SIP [RF= C 3261]
=A0 =A0 =A0 =A0 and SDP
=A0 =A0 =A0 =A0 =A0 =A0 offer/answer [RFC 3264]. The details with regards t= o this
=A0 =A0 =A0 =A0 =A0 =A0 signaling are provided in the solution documents. I= n
=A0 =A0 =A0 =A0 addition to
=A0 =A0 =A0 =A0 =A0 =A0 basic SIP & SDP offer/answer, CLUE specific sig= naling is
=A0 =A0 =A0 =A0 required
=A0 =A0 =A0 =A0 =A0 =A0 to exchange the information describing the multiple= media
=A0 =A0 =A0 =A0 streams.
=A0 =A0 =A0 =A0 =A0 =A0 The details of this signaling and the information r= equired
=A0 =A0 =A0 =A0 to be
=A0 =A0 =A0 =A0 =A0 =A0 exchanged is described in subsequent sections of th= is
=A0 =A0 =A0 =A0 document.

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

=A0 =A0 =A0 =A0 =A0 =A0 SDP O/A, but not until the end of section 4. It doe= s seem
=A0 =A0 =A0 =A0 better
=A0 =A0 =A0 =A0 =A0 =A0 to say it earlier./*

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

[MB2] I don't disagree with what you say but I don't think we shoul= d say anything about that given our charter, which limits the work to SIP. = That's opening up the question as to how that will work, whether additi= onal specification is required,etc. =A0[/MB2]



[CNG] I appreciate CLUE is chartered to specify how CLUE works with SIP. I = don't think anyone wants to preclude the widespread use of CLUE so I th= ink it is worthwhile to specify that CLUE can only be used with SIP. If its= a question of addition specification etc. I think we can simply some text = saying that we're not working on them: e.g. "Whilst "SIP and = SDP O/A" are discussed it does not prevent CLUE from being used in net= works where there are other call controls however the use of these is not c= onsidered nor described by the framework."


--047d7bdc15ac40153704e5175e98-- From iesg-secretary@ietf.org Thu Aug 29 12:55:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E43A11E817F; Thu, 29 Aug 2013 12:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y26b7ORn24u7; Thu, 29 Aug 2013 12:54:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FEB11E8168; Thu, 29 Aug 2013 12:54:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130829195448.29416.88259.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2013 12:54:48 -0700 Cc: clue@ietf.org Subject: [clue] CLUE WG Virtual Interim Meeting, September 17, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 19:55:00 -0000 The CLUE WG will hold an Interim meeting on: Sept. 17, 2013 13.30-15.30 UTC (starting at 6.30 Pacific, 8.30 Central, 9.30 Eastern) Webex details and the preliminary agenda are available on the CLUE WG = wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki From pkyzivat@alum.mit.edu Thu Aug 29 13:51: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 3151F11E816F for ; Thu, 29 Aug 2013 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.334 X-Spam-Level: X-Spam-Status: No, score=-0.334 tagged_above=-999 required=5 tests=[AWL=0.103, 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 YDT1mQHWIiRs for ; Thu, 29 Aug 2013 13:51:36 -0700 (PDT) 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 BB6E711E8134 for ; Thu, 29 Aug 2013 13:51:35 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id Jagw1m0051ei1Bg5CkrTKq; Thu, 29 Aug 2013 20:51:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id JkrS1m02A3ZTu2S3kkrTjm; Thu, 29 Aug 2013 20:51:27 +0000 Message-ID: <521FB44E.30802@alum.mit.edu> Date: Thu, 29 Aug 2013 16:51:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE 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=1377809487; bh=icHzkqwi+ITHdXt/wgyYLe+3ihqJJQaNOGxWwFvqoiw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CYCXHREpW583Q68uKL4G3XF1CWu4BVDAAt01suetOREHNGwGEcgC33nblVmZjr8Eo POYBwR/gCWSuFq6VydQUFC1ytZK0xBYyn0BBA7+WqF6OGpJ/Ra/KBn8WKmdEbLjA9i pZEdyUfNqR9fbWrtzhVgT4W4gsYNnxE+VCccJa2LGq8UoTI7qMyrGaED6r/tq8lXvI 25tpof3ls36tGxAX5zVfNCb3axzS5Aou9TBDtNcAZSrHxm69PioUJ0j2zSyRV9khpW jhUFUFRB5OqKJW5DQQEIGzcdJXG/6yUCFccre8Y7a7ysdBRN/r7pdf1NX0oGSwmBio bIRC9fY3sKlZg== Subject: [clue] Next Steps on CLUE Signaling **PLEASE READ** 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, 29 Aug 2013 20:51:43 -0000 Hey all CLUE signaling fans! (This is a little long, but please read.) I hope you are all now recovered from Berlin, and now ready to get back to work. As you should have seen by now, we are about to start up design team calls again, with a primary focus on signaling. To get CLUE done, we really really need to have a signaling document in reasonable shape by the Vancouver meeting. And that isn't a lot of time. By "reasonable shape", I mean that all the major decisions have been made, and reflected as substance in the document. I'll be satisfied with that. It doesn't have to be pretty. (Getting the document entirely consistent, readable, pretty, with all the necessary boiler plate can wait.) We had a number of "volunteers" who expressed an interest in working on signaling, in addition to me: Simon, Christer, Rob, Roni. Jonathan expressed interest, but very limited time. I'm hoping that Simon was also volunteering Roberta. Are all of those mentioned above able to participate in the design team calls? (Please confirm.) When I talked about signaling in Berlin I broke it down into a number of open issues. (See the slides for details.) Some are bigger than others. I'd like to get somebody to volunteer to take the lead on each of these. I have some ideas who would be good based on comments on past contributions: o Relationship between CLUE messages & SDP (Rob) o Representation of encodings: SDP or ADV (Rob) o Approach to message responses (Simon/Roberta) o Elaboration of message sequencing (Simon/Roberta) o Legacy mode (Christer) o CLUE channel (Paul/Christer) o Message Syntax Details (Simon/Roberta) o Approach to versioning/options/extensions (Paul) o Approach to message encoding: stand-alone or deltas o Examples/call flows Please comment on the "assignments" I made above: Are you ok with having your name where I put it? Do you really want your name on something else? My thought is to focus each design team meeting on one issue, or some closely coupled issues. And to have the lead person for that issue make a proposal and discuss it. As we go, we can update the document. I'm willing to do the actual editing, or others can do it themselves if that is easier. I propose that we start with some "easy" topics, in order to get the ball rolling and make some progress. That will also give others time to work up proposals for the harder issues. (Discussions on the mailing list on any of the issues is strongly recommended.) The easy ones I have in mind are Versioning(...) and the CLUE channel. I'm willing to take the lead regarding Versioning on the first call of the new series, September 10. The September 17 meeting is preempted by our virtual interim. Perhaps we should defer detailed scheduling of following meetings until then. I'll be available for the Sept 24 meeting, but I'll be traveling much of the prior week, so not able to do much prep. So it would be good if somebody else can take the lead that day. Thanks, Paul (as co-chair) From pkyzivat@alum.mit.edu Thu Aug 29 14:14: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 041F811E8186 for ; Thu, 29 Aug 2013 14:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.336 X-Spam-Level: X-Spam-Status: No, score=-0.336 tagged_above=-999 required=5 tests=[AWL=0.101, 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 JE7xEtJ8C9V5 for ; Thu, 29 Aug 2013 14:14:04 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 117F611E8134 for ; Thu, 29 Aug 2013 14:14:03 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id JiPS1m0031c6gX857lE3XT; Thu, 29 Aug 2013 21:14:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id JlE31m0053ZTu2S3jlE33y; Thu, 29 Aug 2013 21:14:03 +0000 Message-ID: <521FB99A.3090301@alum.mit.edu> Date: Thu, 29 Aug 2013 17:14:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377810843; bh=1P0KWinR+JNiWM8k0ieNZF+aAYldwbwqdL+3QeiMlrI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PX/wUIyMC6BkUZ3JmDwzQ7IWgLTyMfccn/YjcM1KbRSOSJ8gOV2r7ajhmtW1xqoV+ eltHk5mU9bXoicbB+FBNoaDIkVyzlfrOH0/w7gxi0dp5M7qyGvkn8MCBbaHHO5dBUS cCdbRpGfg0os93n90ZCzIyltkBbxC46wmx9ALm4mRZL4jBqs8w5irA0YcztxtXAmdR OZzm+eyDOmfuAd+iAzQl8JClC5fWhuj4sZd50uiSRAasKtAizbVTqz94KQw+FgT0CT cOMDyZbo53OIHlHmKdFWnzZRRS7DXHPtud71JmmQ5JyMQ+NnBJgOHN9TRohh2wF4mD wm7G+j3cNsMOw== Subject: [clue] Query: how to handle extensibility of xml schemas 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, 29 Aug 2013 21:14:10 -0000 XML experts, Is there something good to read on ways for applications to handle the evolution of XML schemas? (How to future-proof both the schema and the applications that use it.) Thanks, Paul From christer.holmberg@ericsson.com Thu Aug 29 23:49:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3549A11E81A2 for ; Thu, 29 Aug 2013 23:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-mM54r2rPU3 for ; Thu, 29 Aug 2013 23:48:58 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB2911E80E4 for ; Thu, 29 Aug 2013 23:48:58 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-89-52204058bae7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A0.43.22048.85040225; Fri, 30 Aug 2013 08:48:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Fri, 30 Aug 2013 08:48:55 +0200 From: Christer Holmberg To: Paul Kyzivat , CLUE Thread-Topic: [clue] Next Steps on CLUE Signaling **PLEASE READ** Thread-Index: AQHOpPmZgLQwZkg1TkershGyMM1kF5mtT+fg Date: Fri, 30 Aug 2013 06:48:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C480666@ESESSMB209.ericsson.se> References: <521FB44E.30802@alum.mit.edu> In-Reply-To: <521FB44E.30802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW6kg0KQwY8ORov9py4zW6zYcIDV gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4M3EqY0GzTMXxvUdZGhgPi3UxcnJICJhI LH18gxXCFpO4cG89WxcjF4eQwGFGiWkP3rCDJIQEljBK3NtQ0sXIwcEmYCHR/U8bJCwiYCcx f8tVsF5hAQeJB7sfMELEHSWW/97ECmEbSczZv5gJxGYRUJVY0rMNrIZXwFfiwI4tLBDjNSUe 9PSBreIU0JJY/vojmM0IdM/3U2vAepkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/0HdryjR/rSB EaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL zTcxAiPh4JbfBjsYN90XO8QozcGiJM67We9MoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG JV9uVLqFyi8sXJ1uIrNvqs3cY/uCHJUcXdlnnnXtUjpnvn6H4LnD5+8d7KpjOeHW9O84E69y wrbp3oWmj26d/PH9qNuaPaEOUl0LP91etFt10p8H53ZsjCns+1o5P0RH59DnPy+MEnR2sWpz +z6XXZLV2Kf4T9nddW68h0zCbMZDr7+e+dp2U4mlOCPRUIu5qDgRAI1yCIRSAgAA Subject: Re: [clue] Next Steps on CLUE Signaling **PLEASE READ** 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, 30 Aug 2013 06:49:05 -0000 Hi, I have been working on some legacy text, and should have something to share= shortly. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: 29. elokuuta 2013 23:51 To: CLUE Subject: [clue] Next Steps on CLUE Signaling **PLEASE READ** Hey all CLUE signaling fans! (This is a little long, but please read.) I hope you are all now recovered from Berlin, and now ready to get back to = work. As you should have seen by now, we are about to start up design team = calls again, with a primary focus on signaling. To get CLUE done, we really really need to have a signaling document in rea= sonable shape by the Vancouver meeting. And that isn't a lot of time. By "reasonable shape", I mean that all the major decisions have been made, = and reflected as substance in the document. I'll be satisfied with that. It= doesn't have to be pretty. (Getting the document entirely consistent, read= able, pretty, with all the necessary boiler plate can wait.) We had a number of "volunteers" who expressed an interest in working on sig= naling, in addition to me: Simon, Christer, Rob, Roni. Jonathan expressed i= nterest, but very limited time. I'm hoping that Simon was also volunteering= Roberta. Are all of those mentioned above able to participate in the design team cal= ls? (Please confirm.) When I talked about signaling in Berlin I broke it down into a number of op= en issues. (See the slides for details.) Some are bigger than others.=20 I'd like to get somebody to volunteer to take the lead on each of these.=20 I have some ideas who would be good based on comments on past contributions= : o Relationship between CLUE messages & SDP (Rob) o Representation of encodi= ngs: SDP or ADV (Rob) o Approach to message responses (Simon/Roberta) o Ela= boration of message sequencing (Simon/Roberta) o Legacy mode (Christer) o C= LUE channel (Paul/Christer) o Message Syntax Details (Simon/Roberta) o Appr= oach to versioning/options/extensions (Paul) o Approach to message encoding= : stand-alone or deltas o Examples/call flows Please comment on the "assignments" I made above: Are you ok with having your name where I put it? Do you really want your name on something else? My thought is to focus each design team meeting on one issue, or some close= ly coupled issues. And to have the lead person for that issue make a propos= al and discuss it. As we go, we can update the document. I'm willing to do the actual editing,= or others can do it themselves if that is easier. I propose that we start with some "easy" topics, in order to get the ball r= olling and make some progress. That will also give others time to work up p= roposals for the harder issues. (Discussions on the mailing list on any of = the issues is strongly recommended.) The easy ones I have in mind are Versioning(...) and the CLUE channel. I'm willing to take the lead regarding Versioning on the first call of the = new series, September 10. The September 17 meeting is preempted by our virtual interim. Perhaps we sh= ould defer detailed scheduling of following meetings until then. I'll be available for the Sept 24 meeting, but I'll be traveling much of th= e prior week, so not able to do much prep. So it would be good if somebody = else can take the lead that day. Thanks, Paul (as co-chair) _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From spromano@unina.it Fri Aug 30 03:03: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 BE76721E80C0 for ; Fri, 30 Aug 2013 03:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.418 X-Spam-Level: X-Spam-Status: No, score=-98.418 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MANGLED_LIMITD=2.3, 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 DMWwjtuE0tNG for ; Fri, 30 Aug 2013 03:03:49 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id CD59A21E80A3 for ; Fri, 30 Aug 2013 03:03:47 -0700 (PDT) Received: from [1.131.207.61] ([37.101.81.184]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r7UA3fPg011331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 30 Aug 2013 12:03:42 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <521FB44E.30802@alum.mit.edu> References: <521FB44E.30802@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----8WPBV07KV0BZNSEY59X1FHIC22RZUA" From: Simon Pietro Romano Date: Fri, 30 Aug 2013 12:03:38 +0200 To: Paul Kyzivat , CLUE Message-ID: <65ee2af5-e837-46cc-b2fb-2ccfab0e94a5@email.android.com> Subject: Re: [clue] Next Steps on CLUE Signaling **PLEASE READ** 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, 30 Aug 2013 10:03:54 -0000 ------8WPBV07KV0BZNSEY59X1FHIC22RZUA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Paul, the proposed approach and breakdown of work look good to me (and to Roberta as well). We're already working on CLUE related stuff and we'll keep you all updated on this list. Simon Paul Kyzivat ha scritto: >Hey all CLUE signaling fans! > >(This is a little long, but please read.) > >I hope you are all now recovered from Berlin, and now ready to get back > >to work. As you should have seen by now, we are about to start up >design >team calls again, with a primary focus on signaling. > >To get CLUE done, we really really need to have a signaling document in > >reasonable shape by the Vancouver meeting. And that isn't a lot of >time. >By "reasonable shape", I mean that all the major decisions have been >made, and reflected as substance in the document. I'll be satisfied >with >that. It doesn't have to be pretty. (Getting the document entirely >consistent, readable, pretty, with all the necessary boiler plate can >wait.) > >We had a number of "volunteers" who expressed an interest in working on > >signaling, in addition to me: Simon, Christer, Rob, Roni. Jonathan >expressed interest, but very limited time. I'm hoping that Simon was >also volunteering Roberta. > >Are all of those mentioned above able to participate in the design team > >calls? (Please confirm.) > >When I talked about signaling in Berlin I broke it down into a number >of >open issues. (See the slides for details.) Some are bigger than others. > >I'd like to get somebody to volunteer to take the lead on each of >these. >I have some ideas who would be good based on comments on past >contributions: > >o Relationship between CLUE messages & SDP (Rob) >o Representation of encodings: SDP or ADV (Rob) >o Approach to message responses (Simon/Roberta) >o Elaboration of message sequencing (Simon/Roberta) >o Legacy mode (Christer) >o CLUE channel (Paul/Christer) >o Message Syntax Details (Simon/Roberta) >o Approach to versioning/options/extensions (Paul) >o Approach to message encoding: stand-alone or deltas >o Examples/call flows > >Please comment on the "assignments" I made above: >Are you ok with having your name where I put it? >Do you really want your name on something else? > >My thought is to focus each design team meeting on one issue, or some >closely coupled issues. And to have the lead person for that issue make > >a proposal and discuss it. > >As we go, we can update the document. I'm willing to do the actual >editing, or others can do it themselves if that is easier. > >I propose that we start with some "easy" topics, in order to get the >ball rolling and make some progress. That will also give others time to > >work up proposals for the harder issues. (Discussions on the mailing >list on any of the issues is strongly recommended.) > >The easy ones I have in mind are Versioning(...) and the CLUE channel. >I'm willing to take the lead regarding Versioning on the first call of >the new series, September 10. > >The September 17 meeting is preempted by our virtual interim. Perhaps >we >should defer detailed scheduling of following meetings until then. > >I'll be available for the Sept 24 meeting, but I'll be traveling much >of >the prior week, so not able to do much prep. So it would be good if >somebody else can take the lead that day. > > Thanks, > Paul (as co-chair) >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------8WPBV07KV0BZNSEY59X1FHIC22RZUA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello Paul,

the proposed approach and breakdown of work look good to me (and to Roberta as well).

We're already working on CLUE related stuff and we'll keep you all updated on this list.

Simon

Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
Hey all CLUE signaling fans!

(This is a little long, but please read.)

I hope you are all now recovered from Berlin, and now ready to get back 
to work. As you should have seen by now, we are about to start up design 
team calls again, with a primary focus on signaling.

To get CLUE done, we really really need to have a signaling document in 
reasonable shape by the Vancouver meeting. And that isn't a lot of time.
By "reasonable shape", I mean that all the major decisions have been 
made, and reflected as substance in the document. I'll be satisfied with 
that. It doesn't have to be pretty. (Getting the document entirely 
consistent, readable, pretty, with all the necessary boiler plate can wait.)

We had a number of "volunteers" who expressed an interest in working on 
signaling, in addition to me: Simon, Christer, Rob, Roni. Jonathan 
expressed interest, but very limi!
 ted
time. I'm hoping that Simon was 
also volunteering Roberta.

Are all of those mentioned above able to participate in the design team 
calls? (Please confirm.)

When I talked about signaling in Berlin I broke it down into a number of 
open issues. (See the slides for details.) Some are bigger than others. 
I'd like to get somebody to volunteer to take the lead on each of these. 
I have some ideas who would be good based on comments on past contributions:

o Relationship between CLUE messages & SDP (Rob)
o Representation of encodings: SDP or ADV (Rob)
o Approach to message responses (Simon/Roberta)
o Elaboration of message sequencing (Simon/Roberta)
o Legacy mode (Christer)
o CLUE channel (Paul/Christer)
o Message Syntax Details (Simon/Roberta)
o Approach to versioning/options/extensions (Paul)
o Approach to message encoding: stand-alone or deltas
o Examples/call flows
!
 
Please comment on the "assignments" I made above:
Are you ok with having your name where I put it?
Do you really want your name on something else?

My thought is to focus each design team meeting on one issue, or some 
closely coupled issues. And to have the lead person for that issue make 
a proposal and discuss it.

As we go, we can update the document. I'm willing to do the actual 
editing, or others can do it themselves if that is easier.

I propose that we start with some "easy" topics, in order to get the 
ball rolling and make some progress. That will also give others time to 
work up proposals for the harder issues. (Discussions on the mailing 
list on any of the issues is strongly recommended.)

The easy ones I have in mind are Versioning(...) and the CLUE channel.
I'm willing to take the lead regarding Versioning on the first call of 
the new series, September 10.

The
September 17 meeting is preempted by our virtual interim. Perhaps we 
should defer detailed scheduling of following meetings until then.

I'll be available for the Sept 24 meeting, but I'll be traveling much of 
the prior week, so not able to do much prep. So it would be good if 
somebody else can take the lead that day.

 Thanks,
 Paul (as co-chair)

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

------8WPBV07KV0BZNSEY59X1FHIC22RZUA-- From internet-drafts@ietf.org Fri Aug 30 15:39:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071A721F9FF2; Fri, 30 Aug 2013 15:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, 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 sNNLNcdNuM7P; Fri, 30 Aug 2013 15:39:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF1B21F9EF5; Fri, 30 Aug 2013 15:39:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 15:39:24 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 22:39:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-requirements-05.txt Pages : 13 Date : 2013-08-30 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirement= s-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Fri Aug 30 15:43: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 69E2E21F9FB6 for ; Fri, 30 Aug 2013 15:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 hsTZ11GcYuHP for ; Fri, 30 Aug 2013 15:43:19 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6320121F9C4E for ; Fri, 30 Aug 2013 15:43:19 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id n5so963354wev.31 for ; Fri, 30 Aug 2013 15:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9x7E8Rm7mjVs2U2IE5PYvI2m0cnNN5/WINuwNM6ZZa4=; b=LRuHdKiXaX4sxwjlycscQR45tmIhSImjXSm5uV509vLPaLy8NNLMvwd4nDb8/ilvWf oRbgTCA+NkekGrRYlaGxB9c8n/QFe0TFVL/Ft6YP1xX8XZ2uZpHDXp6+SgsCwJFbCYLM DFBzPBWwabyi6qgLLiZWA5/RR45oZFk+8KZvgVTYXk4AcOCk78xWkRco4KwkMLKs9T6d EV4GChJ51QlnsnM6CbllD4/zlwNGIWCPLNKJRgOA9PWbZJvxhYHlMT28+5e2NZ8GrPht 6pFKsDjTn/TP25mittAd8VJ22Y/y3WnjRC66xHphfUQIBTMafyj1Loh8fEGjFd9bM31e umqg== MIME-Version: 1.0 X-Received: by 10.180.187.41 with SMTP id fp9mr4210137wic.33.1377902598538; Fri, 30 Aug 2013 15:43:18 -0700 (PDT) Received: by 10.216.36.69 with HTTP; Fri, 30 Aug 2013 15:43:18 -0700 (PDT) In-Reply-To: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2013 17:43:18 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3844cebcb3b04e531f21d Subject: [clue] Fwd: I-D Action: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 22:43:20 -0000 --001a11c3844cebcb3b04e531f21d Content-Type: text/plain; charset=ISO-8859-1 This update reflects the resolution of the open issues. The document should now be ready for WGLC. Mary. ---------- Forwarded message ---------- From: Date: Fri, Aug 30, 2013 at 5:39 PM Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-05.txt To: i-d-announce@ietf.org Cc: clue@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-requirements-05.txt Pages : 13 Date : 2013-08-30 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue Thu --001a11c3844cebcb3b04e531f21d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This update reflects the resolution of the open issues. = =A0The document should now be ready for WGLC. =A0

Mary.= =A0

---------- Forwarded message --------= --
From: <internet-drafts@ietf.org>
Date: Fri, Aug 30, 2013 at 5:39 PM
Subject: [clue] I-D Action: draft-iet= f-clue-telepresence-requirements-05.txt
To: i-d-announce@ietf.org
Cc: clue@ietf.org



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

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

Abstract:
=A0 =A0This memo discusses the requirements for a specification that enable= s
=A0 =A0telepresence interoperability, by describing the relationship betwee= n
=A0 =A0multiple RTP streams. =A0In addition, the problem statement and
=A0 =A0definitions are also covered herein.


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

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

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


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

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

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