From Christian.Groves@nteczone.com Sun Dec 1 17:04:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC81AE2AD for ; Sun, 1 Dec 2013 17:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haaYRrVrd7vi for ; Sun, 1 Dec 2013 17:04:18 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE2F1AE2A8 for ; Sun, 1 Dec 2013 17:04:18 -0800 (PST) Received: from ppp118-209-199-10.lns20.mel6.internode.on.net ([118.209.199.10]:55286 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VnHvA-0004Kk-14 for clue@ietf.org; Mon, 02 Dec 2013 12:03:32 +1100 Message-ID: <529BDC8E.4010402@nteczone.com> Date: Mon, 02 Dec 2013 12:04:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 01:04:20 -0000 Hello Mary, all, In general I'm OK with expressing coding limits in SDP. However I'm trying to understand what the impact is to the CLUE framework as a result of that decision. Does that then mean the entire encoding group concept (i.e. section 8 and 9 (and relevant examples)) are removed from the framework and that a Capture Encoding is now effectively a CaptureID and reference to an SDP m-line? or? Regards, Christian On 30/11/2013 8:24 AM, Mary Barnes wrote: > HI all, > > As mentioned in the email about the November 26th design team meeting, > there was consensus amongst those on the call that SDP should be used > for expressing encoding limits for CLUE. Rob's presentation had > details as to how it could be done using the CLUE protocol, but it was > decided (amongst those on the call) that we should go with the SDP > approach for now and IF an issue is encountered with that approach as > details are worked we could go back to the alternative proposal > outlined in those charts. > > To move forward, we want to ensure that there is WG consensus for > using SDP for the encoding limits. If anyone has any concerns about > that approach, please post a note explaining why no later than Dec > 9th, 2013. If you weren't at the design team meeting and would like > to express your support for the approach, that's also a good idea. > > Regards, > Mary > As WG co-chair > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From rohanse2@cisco.com Mon Dec 2 08:29:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0D1AC499 for ; Mon, 2 Dec 2013 08:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4PQc-hFj0cb for ; Mon, 2 Dec 2013 08:29:10 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id B018C1A8032 for ; Mon, 2 Dec 2013 08:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2253; q=dns/txt; s=iport; t=1386001748; x=1387211348; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+QGxJJG6jqby+cCKUXdriUnSaNLLj0xuh2IfmDUXFlU=; b=S4xB1AUzw74HGVko/nqzWN96dhrN//onPYe8/JNQO0iZqz7uGtveHwlC Fm2HqWPnNM7W/NOcO/QqlzOc8CHrMSu6pDJEvbeO6CnjrJ66JMlL1RtAs dYlDGBYIQIeyLX6mTaCEgHIKO/wUiO/t2Xn4VpM3nsMLg+/0ZnAohrdDB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFANm0nFKQ/khN/2dsb2JhbABZgwc4uTeBJRZ0giUBAQEEAQEBNTYbCxgJJQ8CFjATBgIBAYd9Db9fEwSOJhEBVxaEHQOMWYs7hkV7ilODKTyBNQ X-IronPort-AV: E=Sophos;i="4.93,811,1378857600"; d="scan'208";a="947843" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 02 Dec 2013 16:29:06 +0000 Received: from [10.47.197.27] ([10.47.197.27]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB2GT0JM002617 for ; Mon, 2 Dec 2013 16:29:02 GMT Message-ID: <529CB55B.80303@cisco.com> Date: Mon, 02 Dec 2013 16:29:15 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <529BDC8E.4010402@nteczone.com> In-Reply-To: <529BDC8E.4010402@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:29:11 -0000 Hi Christian, I don't think this affects Encoding Groups - that concept will still be in the framework and will need to be expressed in CLUE ADVERTISMENT messages, as that's something that isn't well expressible in SDP. The encoding limits referred to are the per-encoding limits. This reflects what we had been taking as our working understanding so far in things like the signalling document, so shouldn't involve a radical rethink. Rob On 02/12/2013 01:04, Christian Groves wrote: > Hello Mary, all, > > In general I'm OK with expressing coding limits in SDP. However I'm > trying to understand what the impact is to the CLUE framework as a > result of that decision. Does that then mean the entire encoding group > concept (i.e. section 8 and 9 (and relevant examples)) are removed from > the framework and that a Capture Encoding is now effectively a CaptureID > and reference to an SDP m-line? or? > > Regards, Christian > > On 30/11/2013 8:24 AM, Mary Barnes wrote: >> HI all, >> >> As mentioned in the email about the November 26th design team meeting, >> there was consensus amongst those on the call that SDP should be used >> for expressing encoding limits for CLUE. Rob's presentation had >> details as to how it could be done using the CLUE protocol, but it was >> decided (amongst those on the call) that we should go with the SDP >> approach for now and IF an issue is encountered with that approach as >> details are worked we could go back to the alternative proposal >> outlined in those charts. >> >> To move forward, we want to ensure that there is WG consensus for >> using SDP for the encoding limits. If anyone has any concerns about >> that approach, please post a note explaining why no later than Dec >> 9th, 2013. If you weren't at the design team meeting and would like >> to express your support for the approach, that's also a good idea. >> >> Regards, >> Mary >> As WG co-chair >> >> >> _______________________________________________ >> 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 Mark.Duckworth@polycom.com Mon Dec 2 12:11:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CC31ADE71 for ; Mon, 2 Dec 2013 12:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ayb126zLyQkr for ; Mon, 2 Dec 2013 12:11:31 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9361AD845 for ; Mon, 2 Dec 2013 12:11:31 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 2 Dec 2013 12:11:28 -0800 From: "Duckworth, Mark" To: Stephen Botzko , Mary Barnes Date: Mon, 2 Dec 2013 12:11:27 -0800 Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: Ac7rv/Slg/aYjnnSRAWhQPn4d9cl1AD2CZHg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> 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_49E45C59CA48264997FEBFB29B6BC2D6046A2945CRPMBOXPRD07pol_" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 20:11:37 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D6046A2945CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments inline. Mark Duckworth From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, November 27, 2013 5:28 PM To: Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf= .org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirem= ents-06.txt Dan - thanks so much for reviewing this. Comments are in-line Stephen Botzko On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes > wrote: On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat > wrote: Authors, What do you think of these comments? If you aren't in agreement with all of them, then we should have a dialog w= ith Dan about them. If in agreement, then lets discuss what changes are appropriate. More inline. On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number = of issues should be clarified before approval. Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wi= kipedia articles (subject to change, subject to attacks) as references, and= I also believe that the current definitions (@11/21/13, US morning hours) = are ambiguous. Actually the Wikipedia article does not include definitions = for Left and Right, and speaks about 'house left' (equal to 'stage right') = and 'house right' (equal to 'stage left'). If another specification in CLUE= will use the terms defined here it is not clear which one is meant. This seems like a reasonable point to me. Is there a more stable reference = we can use? If not, can we just define these terms in the document? [MB] I'm almost of a mind to just remove those definitions. The consensus = was that the terms should be qualified when they are used and the framework= does an excellent job of defining more precise terms that properly qualify= "left" and "right" and differentiate from stage right, etc. as appropriate= . We use "left" and "right" in one place in this requirements document and= I think the use is general enough that we don't need a definition (in this= document). The wikipedia reference has been in the document since day 1 = as a WG document (it was added in -03 of the individual document). The di= scussions around "left"/"right" on the list were in the context of the defi= nitions document and again, consensus was that the terms should be qualifie= d (as they are in the framework), thus I don't think the current definition= s serve any value. [/MB] [SB] I agree with Mary that these definitions can simply be removed. [/SB] [Duckworth, Mark] I agree too. 2. In REQMT-1d it is not clear what 'the extent of individual video capture= s' means 3. In REQMT-2d it is not clear what 'the extent of individual audio capture= s' means We have had our own concerns about this. I think we want to say *something*= but its unclear to me exactly what. Perhaps we could focus on what we want= to use this for, and explicitly leave details of what it is for the FW. [MB] Can you point to the threads of discussion where you feel this concern= with this phrasing has been raised? There were certainly concerns raised= about those requirements (i.e., 3D), but I'm not reading this as Dan's con= cern. My understanding is that the word "extent" is used in the context o= f video imagery from the perspective of the camera - i.e., the "angular ext= ent" or something like that. I think we should replace the word "extent" w= ith something more specific. Anyone have a suggestion? [SB] The intent of REQMT-1d was to say that CLUE needs to identify the area that= each camera captured in the room - so it would be clear how views from dif= ferent camera related to each other, and also if there were any gaps, etc. = Identifying the scale of the view is related, but is captured concisely in= requirement 6. Proper rendering in a multi-camera telepresence system req= uires this knowledge - today it is generally hard-wired into the room desig= n. But that doesn't result in an interoperable experience, and it needs to= be signaled if you want to get appropriate rendering between rooms with di= sparate designs. For audio [REQMT-2d], there is an analogous need to identify the area of co= verage of a microphone. The need to correlate the audio and the video is r= elated, but is captured separately in REQMT-3. The discussions on the list related to audio and video area of coverage wer= e about whether the model in the framework was adequate. Personally I beli= eve it is. But what really matters here is whether we are clearly stating = the requirement, not the adequacy of the proposed specifications. One alternative term is "area of coverage", which is commonly used in surve= illance applications to describe a similar concept. If people think that m= ight be confused with radio coverage (e.g. an LTE coverage map) we could dr= aft a definition and add it to section 3. [/SB] [Duckworth, Mark] I agree with Steve about the intent. I agree "area of co= verage" is a better term than "extent" for this purpose. And, note these requirements were added based on discussion at IETF-82: http://www.ietf.org/proceedings/82/slides/clue-1.pdf [/MB] Thanks, Paul 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed. [SB] The intent was to simply state that the solution must not prevent dire= ct interoperability with SIP devices (either phone or videoconferencing) - = without the need for a middlebox to convert signaling (as would be required= with rtcweb for instance). The limitation is simply that telepresence ex= tensions can't be used. I do not see a need to describe the limitations of= existing SIP systems in this requirements document. Suggested text that makes the requirement more clear would be helpful. Thi= s is a bit tricky to word, since SIP itself has no requirement that says SI= P endpoints must interoperate with each other w/o middleboxes to assist. An= d in fact they often don't. We could alternatively drop the requirement. [/SB] [Duckworth, Mark] I agree with Steve about the intent. How about something= like "The solution must make it possible for devices that support CLUE to = interoperate directly with SIP devices that do not support CLUE" ? 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations [SB]At this point I am not certain either. We might have meant that differ= ent use cases had different placements, number, and size of presentations. = Or that existing telepresence systems handle presentations in different way= s. It is not worded as a clear requirement, and it says "can", not "should" or= "must". My recommendation is to delete that bullet. [/SB] [Duckworth, Mark] I think we meant this: - There can be multiple simultaneous presentation media stream= s - Presentation media streams can be spatially related to each o= ther 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or= extending the specifications for new functionality in the future? [SB] What is meant is extending the specifications for new functionality in= the future. I suggest that we re-word to "New protocols developed for the= solution MUST include extensibility mechanisms" [/SB] [Duckworth, Mark] Steve's suggestion is more clear. Minor issues: 1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is. [SB] I am not sure if the CLUE WG has a recommended order for reading the v= arious documents. Personally I would recommend that people start with the = use cases. In any event, I think the document purpose is properly captured= in the abstract - it is not intended to be an introduction to telepresence= generally or as an orientation to CLUE specifications. [/SB] [Duckworth, Mark] I agree. 2. In the Introduction Section I see: These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is= ambiguous. It would be good to mention (again) in section 5 that by what i= s meant by the 'solution' is the definition of the protocol, not the implem= entation. [SB] I agree. We should also use "specifications", since current plans cal= l for more than one standards-track RFC [/SB] [Duckworth, Mark] I agree 3. I will defer to the Security Review to comment whether REQMT-18 is enoug= h from a security point of view - especially as the information about media= captures may include explicitly or implicitly details about equipment on e= ach site, etc. To me it seems a little bit too vague. [SB] I don't see it as vague - it pretty clearly says that only the mechani= sm needs to be secure. I think you are saying that the security section mi= ght be incomplete. Current protocol designs do not include explicit details about equipment, a= nd I see nothing in the requirements that suggest otherwise. Some requirem= ents do require transport of information that can be used infer room dimens= ions (at least of the visible portion of the room) and the audio/video cove= rage within it. Can you identify threats that might use that information? Of course each specification includes its own Security Considerations. Obvi= ously we will address any security review comments in this one. [/SB]. Regards, Dan --_000_49E45C59CA48264997FEBFB29B6BC2D6046A2945CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments = inline.

Mark Duckworth

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4= .0pt'>

From: clue [mailto:clue-bounces@ietf= .org] On Behalf Of Stephen Botzko
Sent: Wednesday, Novembe= r 27, 2013 5:28 PM
To: Mary Barnes
Cc: draft-ietf-clue-= telepresence-requirements.all@tools.ietf.org; clue@ietf.org
Subject:<= /b> Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-= 06.txt

 

Dan - thanks so much for reviewing this.
Comments are in-line

 

Stephen Botzko=

 

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

On Thu, Nov = 21, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

<= /div>

Authors,

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

If in agreement, then lets discuss what changes are ap= propriate.

More inline.


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

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

<http://wiki.too= ls.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve the= se comments along with any other Last Call comments you may receive.
Document: draft-ietf-clue-telepresence-requirements-06.txt
Reviewer: Da= n Romascanu
Review Date: 11/21/13
IETF LC End Date: 11/27/13
IESG = Telechat date: (if known)

Summary: It's a good and well written docu= ment, almost ready, but a number of issues should be clarified before appro= val.

Major issues:

1. The definitions of Left and Right in Se= ction 3 use an entry article in Wikipedia ('Stage Directions'). I am both u= ncomfortable with the usage of Wikipedia articles (subject to change, subje= ct to attacks) as references, and I also believe that the current definitio= ns (@11/21/13, US morning hours) are ambiguous. Actually the Wikipedia arti= cle does not include definitions for Left and Right, and speaks about 'hous= e left' (equal to 'stage right') and 'house right' (equal to 'stage left').= If another specification in CLUE will use the terms defined here it is not= clear which one is meant.

 

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

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

<= /div>

[SB] I agree with Mary that thes= e definitions can simply be removed.
[/SB]

[Duckworth, Mark] I agree too.=

 

2. In REQMT-1d it is not clear w= hat 'the extent of individual video captures' means

3. In REQMT-2d i= t is not clear what 'the extent of individual audio captures' means

 

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

[MB]= Can you point to the threads of discussion where you feel this concern wit= h this phrasing has been raised?   There were certainly concerns raise= d about those requirements (i.e., 3D), but I'm not reading this as Dan's co= ncern.   My understanding is that the word "extent" is used = in the context of video imagery from the perspective of the camera - i.e., = the "angular extent" or something like that.  I think we sho= uld replace the word "extent" with something more specific.  = ;Anyone have a suggestion? 

[SB]

The intent of REQMT-1d was to say that CLUE needs to identify = the area that each camera captured in the room - so it would be clear how v= iews from different camera related to each other, and also if there were an= y gaps, etc.  Identifying the scale of the view is related, but is cap= tured concisely in requirement 6.  Proper rendering in a multi-camera = telepresence system requires this knowledge - today it is generally hard-wi= red into the room design.  But that doesn't result in an interoperable= experience, and it needs to be signaled if you want to get appropriate ren= dering between rooms with disparate designs.

 

For au= dio [REQMT-2d], there is an analogous need to identify the area of coverage= of a microphone.  The need to correlate the audio and the video is re= lated, but is captured separately in REQMT-3.

 

The discussions on the list related to audio and = video area of coverage were about whether the model in the framework was ad= equate.  Personally I believe it is.  But what really matters her= e is whether we are clearly stating the requirement, not the adequac= y of the proposed specifications. 

One alternative term is "area of coverage", which is= commonly used in surveillance applications to describe a similar concept.&= nbsp; If people think that might be confused with radio coverage (e.g. an L= TE coverage map) we could draft a definition and add it to section 3.<= /o:p>

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.&= nbsp; I agree “area of coverage” is a better term than “e= xtent” for this purpose.

<= /div>

 

 

And, note these requi= rements were added based on discussion at IETF-82:

http://www.ietf.org/proceedings/82/slides/clu= e-1.pdf

 

 [/MB]

=         Thanks,
        Paul

 

4. REQMT-10: The solution MUST make it possible for endpoi= nts without
               suppo= rt for telepresence extensions to participate in a
      =          telepresence session with those that do.<= br>
More clarity is needed to explain what level of participation in a s= ession (and what limitations) are expected from endpoints that do not suppo= rt the telepresence extensions. I assume there are limitations, otherwise e= xtensions would not be needed.

[SB] The intent was to simply state that the solution must not prevent di= rect interoperability with SIP devices (either phone or videoconferencing) = - without the need for a middlebox to convert signaling (as would be requir= ed with rtcweb for instance).   The limitation is simply that telepres= ence extensions can't be used.  I do not see a need to describe the li= mitations of existing SIP systems in this requirements document. 
=
Suggested text that makes the requirement more clear would be helpful.&= nbsp; This is a bit tricky to word, since SIP itself has no requirement tha= t says SIP endpoints must interoperate with each other w/o middleboxes to a= ssist. And in fact they often don't.  We could alternatively drop the = requirement.

[/SB]=

[Duckworth, Mark] I agree with Steve = about the intent.  How about something like “The solution must m= ake it possible for devices that support CLUE to interoperate directly with= SIP devices that do not support CLUE” ?

=


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

*  There can be var= iation in placement, number and size of
        &nbs= p;         presentations

[SB]At this point I am not certain either.  We might h= ave meant that different use cases had different placements, number, and si= ze of presentations. Or that existing telepresence systems handle presentat= ions in different ways. 

It is not worded as a clear requireme= nt, and it says "can", not "should" or "must"= .  My recommendation is to delete that bullet.
[/SB]

=

[Duckworth, Mark] I think we meant this:<= o:p>

 &nb= sp;           - There can be multiple simultaneous prese= ntation media streams

       = ;     - Pr= esentation media streams can be spatially related to each other<= /span>

&= nbsp;            

<= div>

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

What 'ex= tensibility' is meant here? Extending the telepresence sessions, or extendi= ng the specifications for new functionality in the future?

[SB] What is meant is extending the specifica= tions for new functionality in the future.  I suggest that we re-word = to "New protocols developed for the solution MUST include extensibilit= y mechanisms"
[/SB]

[Duckworth, Mark] Steve’s suggestion is more clear.<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>

=



Minor issues:
1. If this is the first and basic document to be read by somebody who= starts to browse through the CLUE specifications, it would be good to defi= ne or expand some place in the introduction what CLUE is.

[SB] I am not sure if the CLUE WG has a recomm= ended order for reading the various documents.  Personally I would rec= ommend that people start with the use cases.  In any event, I think th= e document purpose is properly captured in the abstract - it is not intende= d to be an introduction to telepresence generally or as an orientation to C= LUE specifications.
[/SB]

[Duckworth, Mark] I agree.

 

2. In the Introduction Section I see:

&= nbsp; These

    requirements a= re for the specification, they are not requirements on
    the= telepresence systems implementing the solution/protocol that will
 = ;   be specified.

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

[SB] I agree.  We should also use "specifications&qu= ot;, since current plans call for more than one standards-track RFC
[/SB= ]

[Duckworth, Mark] I agre= e


3. I will defer to the Security R= eview to comment whether REQMT-18 is enough from a security point of view -= especially as the information about media captures may include explicitly = or implicitly details about equipment on each site, etc. To me it seems a l= ittle bit too vague.

[SB] I don't see it as vague - it pretty clearly say= s that only the mechanism needs to be secure.  I think you are saying = that the security section might be incomplete.

Current protocol des= igns do not include explicit details about equipment, and I see nothing in = the requirements that suggest otherwise.  Some requirements do require= transport of information that can be used infer room dimensions (at least = of the visible portion of the room) and the audio/video coverage within it.=   Can you identify threats that might use that information? 

O= f course each specification includes its own Security Considerations. Obvio= usly we will address any security review comments in this one.
[/SB].


Regards,

Dan

<= /blockquote>

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D6046A2945CRPMBOXPRD07pol_-- From michael.hammer@yaanatech.com Mon Dec 2 12:34:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285D21ADF27 for ; Mon, 2 Dec 2013 12:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K544HS6FHnQA for ; Mon, 2 Dec 2013 12:34:07 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 289E51AD845 for ; Mon, 2 Dec 2013 12:34:07 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Mon, 2 Dec 2013 12:34:04 -0800 From: Michael Hammer To: "Mark.Duckworth@polycom.com" , "stephen.botzko@gmail.com" , "mary.ietf.barnes@gmail.com" Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: AQHO75q3QGn3Moivc0CbjSyjQMSuR5pBWs8g Date: Mon, 2 Dec 2013 20:34:04 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.171] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_036A_01CEEF73.ED6BDE30" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 20:34:13 -0000 ------=_NextPart_000_036A_01CEEF73.ED6BDE30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_036B_01CEEF73.ED6BDE30" ------=_NextPart_001_036B_01CEEF73.ED6BDE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Requirement 15 is written in language that is more vague than the other requirements. I would argue that what it says is already covered by the other requirements and could be removed with no harm. For example Reqts 2 and 4 seem to say that there will be multiple devices involved in creating a "presentation". And 5-9 seem to cover various interop issues with different numbers and types of devices. Also, presentation is not defined. Mike From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, December 02, 2013 3:11 PM To: Stephen Botzko; Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Comments inline. Mark Duckworth From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, November 27, 2013 5:28 PM To: Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Dan - thanks so much for reviewing this. Comments are in-line Stephen Botzko On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes wrote: On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat wrote: Authors, What do you think of these comments? If you aren't in agreement with all of them, then we should have a dialog with Dan about them. If in agreement, then lets discuss what changes are appropriate. More inline. On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number of issues should be clarified before approval. Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wikipedia articles (subject to change, subject to attacks) as references, and I also believe that the current definitions (@11/21/13, US morning hours) are ambiguous. Actually the Wikipedia article does not include definitions for Left and Right, and speaks about 'house left' (equal to 'stage right') and 'house right' (equal to 'stage left'). If another specification in CLUE will use the terms defined here it is not clear which one is meant. This seems like a reasonable point to me. Is there a more stable reference we can use? If not, can we just define these terms in the document? [MB] I'm almost of a mind to just remove those definitions. The consensus was that the terms should be qualified when they are used and the framework does an excellent job of defining more precise terms that properly qualify "left" and "right" and differentiate from stage right, etc. as appropriate. We use "left" and "right" in one place in this requirements document and I think the use is general enough that we don't need a definition (in this document). The wikipedia reference has been in the document since day 1 as a WG document (it was added in -03 of the individual document). The discussions around "left"/"right" on the list were in the context of the definitions document and again, consensus was that the terms should be qualified (as they are in the framework), thus I don't think the current definitions serve any value. [/MB] [SB] I agree with Mary that these definitions can simply be removed. [/SB] [Duckworth, Mark] I agree too. 2. In REQMT-1d it is not clear what 'the extent of individual video captures' means 3. In REQMT-2d it is not clear what 'the extent of individual audio captures' means We have had our own concerns about this. I think we want to say *something* but its unclear to me exactly what. Perhaps we could focus on what we want to use this for, and explicitly leave details of what it is for the FW. [MB] Can you point to the threads of discussion where you feel this concern with this phrasing has been raised? There were certainly concerns raised about those requirements (i.e., 3D), but I'm not reading this as Dan's concern. My understanding is that the word "extent" is used in the context of video imagery from the perspective of the camera - i.e., the "angular extent" or something like that. I think we should replace the word "extent" with something more specific. Anyone have a suggestion? [SB] The intent of REQMT-1d was to say that CLUE needs to identify the area that each camera captured in the room - so it would be clear how views from different camera related to each other, and also if there were any gaps, etc. Identifying the scale of the view is related, but is captured concisely in requirement 6. Proper rendering in a multi-camera telepresence system requires this knowledge - today it is generally hard-wired into the room design. But that doesn't result in an interoperable experience, and it needs to be signaled if you want to get appropriate rendering between rooms with disparate designs. For audio [REQMT-2d], there is an analogous need to identify the area of coverage of a microphone. The need to correlate the audio and the video is related, but is captured separately in REQMT-3. The discussions on the list related to audio and video area of coverage were about whether the model in the framework was adequate. Personally I believe it is. But what really matters here is whether we are clearly stating the requirement, not the adequacy of the proposed specifications. One alternative term is "area of coverage", which is commonly used in surveillance applications to describe a similar concept. If people think that might be confused with radio coverage (e.g. an LTE coverage map) we could draft a definition and add it to section 3. [/SB] [Duckworth, Mark] I agree with Steve about the intent. I agree "area of coverage" is a better term than "extent" for this purpose. And, note these requirements were added based on discussion at IETF-82: http://www.ietf.org/proceedings/82/slides/clue-1.pdf [/MB] Thanks, Paul 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session (and what limitations) are expected from endpoints that do not support the telepresence extensions. I assume there are limitations, otherwise extensions would not be needed. [SB] The intent was to simply state that the solution must not prevent direct interoperability with SIP devices (either phone or videoconferencing) - without the need for a middlebox to convert signaling (as would be required with rtcweb for instance). The limitation is simply that telepresence extensions can't be used. I do not see a need to describe the limitations of existing SIP systems in this requirements document. Suggested text that makes the requirement more clear would be helpful. This is a bit tricky to word, since SIP itself has no requirement that says SIP endpoints must interoperate with each other w/o middleboxes to assist. And in fact they often don't. We could alternatively drop the requirement. [/SB] [Duckworth, Mark] I agree with Steve about the intent. How about something like "The solution must make it possible for devices that support CLUE to interoperate directly with SIP devices that do not support CLUE" ? 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations [SB]At this point I am not certain either. We might have meant that different use cases had different placements, number, and size of presentations. Or that existing telepresence systems handle presentations in different ways. It is not worded as a clear requirement, and it says "can", not "should" or "must". My recommendation is to delete that bullet. [/SB] [Duckworth, Mark] I think we meant this: - There can be multiple simultaneous presentation media streams - Presentation media streams can be spatially related to each other 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or extending the specifications for new functionality in the future? [SB] What is meant is extending the specifications for new functionality in the future. I suggest that we re-word to "New protocols developed for the solution MUST include extensibility mechanisms" [/SB] [Duckworth, Mark] Steve's suggestion is more clear. Minor issues: 1. If this is the first and basic document to be read by somebody who starts to browse through the CLUE specifications, it would be good to define or expand some place in the introduction what CLUE is. [SB] I am not sure if the CLUE WG has a recommended order for reading the various documents. Personally I would recommend that people start with the use cases. In any event, I think the document purpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as an orientation to CLUE specifications. [/SB] [Duckworth, Mark] I agree. 2. In the Introduction Section I see: These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is ambiguous. It would be good to mention (again) in section 5 that by what is meant by the 'solution' is the definition of the protocol, not the implementation. [SB] I agree. We should also use "specifications", since current plans call for more than one standards-track RFC [/SB] [Duckworth, Mark] I agree 3. I will defer to the Security Review to comment whether REQMT-18 is enough from a security point of view - especially as the information about media captures may include explicitly or implicitly details about equipment on each site, etc. To me it seems a little bit too vague. [SB] I don't see it as vague - it pretty clearly says that only the mechanism needs to be secure. I think you are saying that the security section might be incomplete. Current protocol designs do not include explicit details about equipment, and I see nothing in the requirements that suggest otherwise. Some requirements do require transport of information that can be used infer room dimensions (at least of the visible portion of the room) and the audio/video coverage within it. Can you identify threats that might use that information? Of course each specification includes its own Security Considerations. Obviously we will address any security review comments in this one. [/SB]. Regards, Dan ------=_NextPart_001_036B_01CEEF73.ED6BDE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Requirement 15 is written in language that is more vague than the = other requirements.

I would argue that what it says is already covered by the other = requirements and could be removed with no harm.

 

For example Reqts 2 and 4 seem to say that there will be multiple = devices involved in creating a = “presentation”.

And 5-9 seem to cover various interop issues with different numbers = and types of devices.

Also, presentation is not defined.

 

Mike

 

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, = Mark
Sent: Monday, December 02, 2013 3:11 PM
To: = Stephen Botzko; Mary Barnes
Cc: = draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; = clue@ietf.org
Subject: Re: [clue] Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 

Comments inline.

Mark Duckworth

 

From:= = clue [mailto:clue-bounces@ietf.= org] On Behalf Of Stephen Botzko
Sent: Wednesday, = November 27, 2013 5:28 PM
To: Mary Barnes
Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org
Subject: Re: = [clue] Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 

Dan - thanks so much for reviewing = this.

Comments are in-line

 

Stephen Botzko

 

On Thu, = Nov 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> = wrote:

On Thu, Nov 21, = 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

Authors,

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

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

More = inline.



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

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

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

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

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

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

Major issues:

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

 

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

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

[SB] I agree with Mary that these definitions can = simply be removed.
[/SB]

[Duckworth, Mark] I agree too.

 

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

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

 

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

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

[SB]

The intent of REQMT-1d was to say that CLUE needs to = identify the area that each camera captured in the room - so it would be = clear how views from different camera related to each other, and also if = there were any gaps, etc.  Identifying the scale of the view is = related, but is captured concisely in requirement 6.  Proper = rendering in a multi-camera telepresence system requires this knowledge = - today it is generally hard-wired into the room design.  But that = doesn't result in an interoperable experience, and it needs to be = signaled if you want to get appropriate rendering between rooms with = disparate designs.

 

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

 

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

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

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.  I agree = “area of coverage” is a better term than = “extent” for this purpose.

 

 

------=_NextPart_001_036B_01CEEF73.ED6BDE30-- ------=_NextPart_000_036A_01CEEF73.ED6BDE30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw MjIwMzQwMlowIwYJKoZIhvcNAQkEMRYEFM46pnjeCoy+Xf7EMnQet3VO6LQhMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAgEFgTlajGnuWRN4Fuj2PwXe5PGUizBagpfYPu09N 8+6GMZdNmbqdMyHE5VT6ZZj51Gs5AaJTd5HHA0u+7r5+u2PMDguYQ4x+Z6g55aygWp0JeVdQ6+fk Na0gFuN8iejZQl1NGVZosYbO93MJlTN6NYwAtAAEyGcGef2cRh9mdZ4VOFwYmDyEyYydTihU+xaG RakIIZQXaSA6U9lkH63I0hIByJ7/UtMv11irYIrQZ9/KfwcR4rXraRBCKa5GrouLWQsIfA/I5wcs 0EFyOUgZDXc+zRP3RJceJx5dqKPvKXSt7fJk3NsDgA2VZVTOELR3znHo08JkjnVQIX19jqQzegAA AAAAAA== ------=_NextPart_000_036A_01CEEF73.ED6BDE30-- From Christian.Groves@nteczone.com Mon Dec 2 14:54:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991441ADF89 for ; Mon, 2 Dec 2013 14:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9j7Z3gPC-rh for ; Mon, 2 Dec 2013 14:54:44 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28C21ADF87 for ; Mon, 2 Dec 2013 14:54:43 -0800 (PST) Received: from ppp118-209-250-139.lns20.mel6.internode.on.net ([118.209.250.139]:50918 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VncN7-0002rb-7Z for clue@ietf.org; Tue, 03 Dec 2013 09:53:45 +1100 Message-ID: <529D0FAE.1080303@nteczone.com> Date: Tue, 03 Dec 2013 09:54:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> In-Reply-To: <529CB55B.80303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:54:45 -0000 Hello Rob, So we'll keep the encoding group concept but there will be no CLUE encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps etc)? Regards, Christian On 3/12/2013 3:29 AM, Robert Hansen wrote: > Hi Christian, > > I don't think this affects Encoding Groups - that concept will still > be in the framework and will need to be expressed in CLUE ADVERTISMENT > messages, as that's something that isn't well expressible in SDP. The > encoding limits referred to are the per-encoding limits. > > This reflects what we had been taking as our working understanding so > far in things like the signalling document, so shouldn't involve a > radical rethink. > > Rob > > On 02/12/2013 01:04, Christian Groves wrote: >> Hello Mary, all, >> >> In general I'm OK with expressing coding limits in SDP. However I'm >> trying to understand what the impact is to the CLUE framework as a >> result of that decision. Does that then mean the entire encoding group >> concept (i.e. section 8 and 9 (and relevant examples)) are removed from >> the framework and that a Capture Encoding is now effectively a CaptureID >> and reference to an SDP m-line? or? >> >> Regards, Christian >> >> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>> HI all, >>> >>> As mentioned in the email about the November 26th design team meeting, >>> there was consensus amongst those on the call that SDP should be used >>> for expressing encoding limits for CLUE. Rob's presentation had >>> details as to how it could be done using the CLUE protocol, but it was >>> decided (amongst those on the call) that we should go with the SDP >>> approach for now and IF an issue is encountered with that approach as >>> details are worked we could go back to the alternative proposal >>> outlined in those charts. >>> >>> To move forward, we want to ensure that there is WG consensus for >>> using SDP for the encoding limits. If anyone has any concerns about >>> that approach, please post a note explaining why no later than Dec >>> 9th, 2013. If you weren't at the design team meeting and would like >>> to express your support for the approach, that's also a good idea. >>> >>> Regards, >>> Mary >>> As WG co-chair >>> >>> >>> _______________________________________________ >>> 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 dromasca@avaya.com Tue Dec 3 03:37:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1133F1AE118 for ; Tue, 3 Dec 2013 03:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwSj_PNl5nCS for ; Tue, 3 Dec 2013 03:37:25 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 87C461AE116 for ; Tue, 3 Dec 2013 03:37:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFANnBnVKHCzI1/2dsb2JhbABagkMjIThTuGeBHBZ0giYBAQEDEhtMEAIBCA0FECQyFw4CBAENDRqHXwGmKJsGF45NMQeDIIETA5Qxik+LJ4Mpgio X-IronPort-AV: E=Sophos;i="4.93,817,1378872000"; d="scan'208,217";a="39672298" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Dec 2013 06:37:22 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 03 Dec 2013 06:26:28 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Tue, 3 Dec 2013 06:37:20 -0500 From: "Romascanu, Dan (Dan)" To: Stephen Botzko , Mary Barnes Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: AQHO67/3lpfRdohfAEekr7wrGB/gDJpCXzpQ Date: Tue, 3 Dec 2013 11:37:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1294E040@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1294E040AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:37:28 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1294E040AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minor clarification of my comment on a minor issue. What needs definition h= ere is the term CLUE itself. The document talks about 'CLUE will not dictat= e', 'architecture for CLUE', 'CLUE enables', etc., but what is CLUE? (someo= ne may wonder) Regards, Dan Minor issues: 1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is. [SB] I am not sure if the CLUE WG has a recommended order for reading the v= arious documents. Personally I would recommend that people start with the = use cases. In any event, I think the document purpose is properly captured= in the abstract - it is not intended to be an introduction to telepresence= generally or as an orientation to CLUE specifications. [/SB] --_000_9904FB1B0159DA42B0B887B7FA8119CA1294E040AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minor clarification of my= comment on a minor issue. What needs definition here is the term CLUE itse= lf. The document talks about ‘CLUE will not dictate’, ‘ar= chitecture for CLUE’, ‘CLUE enables’, etc., but what is CLUE? (some= one may wonder)

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

 <= /p>


Minor issues:

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

[SB] I am not sure if the CLUE WG has a recommended = order for reading the various documents.  Personally I would recommend= that people start with the use cases.  In any event, I think the docu= ment purpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as= an orientation to CLUE specifications.
[/SB]

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA1294E040AZFFEXMB04globa_-- From christer.holmberg@ericsson.com Tue Dec 3 03:40:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD82A1AE11B for ; Tue, 3 Dec 2013 03:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YOXZj0k1mZy for ; Tue, 3 Dec 2013 03:40:52 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 397361AE119 for ; Tue, 3 Dec 2013 03:40:51 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-fc-529dc33fbd7d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 39.29.03802.F33CD925; Tue, 3 Dec 2013 12:40:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0347.000; Tue, 3 Dec 2013 12:40:47 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? Thread-Index: AQHO7Ulz6eePc9cDLUadPvvhvI2Bw5pCXkBw Date: Tue, 3 Dec 2013 11:40:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C567648@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C567648ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvra7D4blBBnu2clrsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG5OVb2Av2mFQ8mrKCrYHxgm4XIweHhICJ xOOJWl2MnECmmMSFe+vZuhi5OIQEDjFKdGzaww7hLGKUODPxPiNIA5uAhUT3P22QBhEBJ4kL L9+zgNjCAj4Smzo+sUHEfSXWdBxjh7CNJKasfcoEYrMIqEi8eHuCFcTmBao5uP4jI4gtJBAg car1FJjNKRAoMeXScrA5jEAHfT+1BqyXWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4StKHF1 +nKo+nyJudNPMEHsEpQ4OfMJywRGkVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4z IYsvYGRfxciem5iZk15utIkRGDkHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL 4otKc1KLDzEycXBKNTBOkuL5fmTepcTEM3URynMfV7S8L+x3bl1zVHmVWHThScm/sT65ggrz jvxhXmf/7IznyecrHrMLnw5Yud0jnUvtWcUOAf9J7nl/0s+qLDmk8W4P5+4/iz4a7Nh5vGjV NY+fs/9M0NcwVzzOG260xO7DWXMB5b0xp1b633vxdvO9U2ZRF12/FqjHKrEUZyQaajEXFScC AGrXy31qAgAA Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 11:40:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C567648ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was at the design team meeting, but I would still like to express my supp= ort for the approach on the list - just for the record :) Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 29. marraskuuta 2013 23:25 To: CLUE Subject: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? HI all, As mentioned in the email about the November 26th design team meeting, ther= e was consensus amongst those on the call that SDP should be used for expre= ssing encoding limits for CLUE. Rob's presentation had details as to how i= t could be done using the CLUE protocol, but it was decided (amongst those = on the call) that we should go with the SDP approach for now and IF an issu= e is encountered with that approach as details are worked we could go back = to the alternative proposal outlined in those charts. To move forward, we want to ensure that there is WG consensus for using SDP= for the encoding limits. If anyone has any concerns about that approach, = please post a note explaining why no later than Dec 9th, 2013. If you wer= en't at the design team meeting and would like to express your support for = the approach, that's also a good idea. Regards, Mary As WG co-chair --_000_7594FB04B1934943A5C02806D1A2204B1C567648ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

I was at the design team = meeting, but I would still like to express my support for the approach on t= he list – just for the record :)

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: clue [ma= ilto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 29. marraskuuta 2013 23:25
To: CLUE
Subject: [clue] Consensus call: Encoding Limits - SDP or CLUE signal= ing?

 

HI all,

 

As mentioned in the email about the November 26th de= sign team meeting, there was consensus amongst those on the call that SDP s= hould be used for expressing encoding limits for CLUE.  Rob's presenta= tion had details as to how it could be done using the CLUE protocol, but it was decided (amongst those on the cal= l) that we should go with the SDP approach for now and IF an issue is encou= ntered with that approach as details are worked we could go back to the alt= ernative proposal outlined in those charts.  

 

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

 

Regards,

Mary

As WG co-chair

--_000_7594FB04B1934943A5C02806D1A2204B1C567648ESESSMB209erics_-- From Mark.Duckworth@polycom.com Tue Dec 3 06:17:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCD31AE11C for ; Tue, 3 Dec 2013 06:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Ld0Ahg5cck for ; Tue, 3 Dec 2013 06:17:23 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B08CF1ADF7B for ; Tue, 3 Dec 2013 06:17:23 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 3 Dec 2013 06:17:21 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 3 Dec 2013 06:17:19 -0800 Thread-Topic: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? Thread-Index: Ac7vsYGN5fy1aT5oSO+aAaD99C8lNwAgEoxw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> In-Reply-To: <529D0FAE.1080303@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:17:26 -0000 Hello Christian, I agree with Rob, and even further, I think the Framework document is alrea= dy consistent with this approach, because it has been our working understan= ding for quite a while. This text from section 8.1 sums it up nicely: "Individual Encoding parameters are represented in SDP [RFC4566], not in CLUE messages. For example, for a video encoding using H.26x compression technologies, this can include parameters such as: . Maximum bandwidth; . Maximum picture size in pixels; . Maximum number of pixels to be processed per second; The bandwidth parameter is the only one that specifically relates to a CLUE Advertisement, as it can be further constrained by the maximum group bandwidth in an Encoding Group." Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Monday, December 02, 2013 5:55 PM > To: clue@ietf.org > Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signali= ng? >=20 > Hello Rob, >=20 > So we'll keep the encoding group concept but there will be no CLUE encodi= ng > parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps etc)? >=20 > Regards, Christian >=20 > On 3/12/2013 3:29 AM, Robert Hansen wrote: > > Hi Christian, > > > > I don't think this affects Encoding Groups - that concept will still > > be in the framework and will need to be expressed in CLUE ADVERTISMENT > > messages, as that's something that isn't well expressible in SDP. The > > encoding limits referred to are the per-encoding limits. > > > > This reflects what we had been taking as our working understanding so > > far in things like the signalling document, so shouldn't involve a > > radical rethink. > > > > Rob > > > > On 02/12/2013 01:04, Christian Groves wrote: > >> Hello Mary, all, > >> > >> In general I'm OK with expressing coding limits in SDP. However I'm > >> trying to understand what the impact is to the CLUE framework as a > >> result of that decision. Does that then mean the entire encoding > >> group concept (i.e. section 8 and 9 (and relevant examples)) are > >> removed from the framework and that a Capture Encoding is now > >> effectively a CaptureID and reference to an SDP m-line? or? > >> > >> Regards, Christian > >> > >> On 30/11/2013 8:24 AM, Mary Barnes wrote: > >>> HI all, > >>> > >>> As mentioned in the email about the November 26th design team > >>> meeting, there was consensus amongst those on the call that SDP > >>> should be used for expressing encoding limits for CLUE. Rob's > >>> presentation had details as to how it could be done using the CLUE > >>> protocol, but it was decided (amongst those on the call) that we > >>> should go with the SDP approach for now and IF an issue is > >>> encountered with that approach as details are worked we could go > >>> back to the alternative proposal outlined in those charts. > >>> > >>> To move forward, we want to ensure that there is WG consensus for > >>> using SDP for the encoding limits. If anyone has any concerns about > >>> that approach, please post a note explaining why no later than Dec > >>> 9th, 2013. If you weren't at the design team meeting and would like > >>> to express your support for the approach, that's also a good idea. > >>> > >>> Regards, > >>> Mary > >>> As WG co-chair > >>> > >>> > >>> _______________________________________________ > >>> 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 rohanse2@cisco.com Tue Dec 3 06:25:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6DD1AE08F for ; Tue, 3 Dec 2013 06:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-3rxEJiNR_D for ; Tue, 3 Dec 2013 06:25:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id C03881AE082 for ; Tue, 3 Dec 2013 06:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3077; q=dns/txt; s=iport; t=1386080712; x=1387290312; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=9rav6KDqem8dRj/CWgGHUwfgh4aLR90RhhqGBpVvH2I=; b=mQ5g6kMV5KyKWZJvwNBmmTXiaV7kMkuXaY1yjO01srJ20hsGydJ65J13 jkiA2Ptt0aIVD2RuLj4bLWhyHIbPXeC9OLYojDOcoyo3VK1nidWx1LWOn RTvjqQQkou55Jfnud3loPFglWxT1M/Vf9VJU0b+0DWKTVTxshRB6MhUBF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAInpnVKQ/khL/2dsb2JhbABagwc4uTqBGxZ0giUBAQEEAQEBNTYKEQsYCRYPCQMCAQIBFTATBgIBAYd9DcFGEwSOHBEBV4QzA4xZizuGRXuKU4MpPIE1 X-IronPort-AV: E=Sophos;i="4.93,818,1378857600"; d="scan'208";a="1609530" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 03 Dec 2013 14:25:11 +0000 Received: from [10.47.197.27] ([10.47.197.27]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB3EP5l4011954 for ; Tue, 3 Dec 2013 14:25:06 GMT Message-ID: <529DE9D1.2030006@cisco.com> Date: Tue, 03 Dec 2013 14:25:21 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> In-Reply-To: <529D0FAE.1080303@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:25:17 -0000 Hi Christian, That's correct, though the group limits are somewhat orthogonal, and IIRC we agreed to remove them at IETF87. Rob On 02/12/2013 22:54, Christian Groves wrote: > Hello Rob, > > So we'll keep the encoding group concept but there will be no CLUE > encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps etc)? > > Regards, Christian > > On 3/12/2013 3:29 AM, Robert Hansen wrote: >> Hi Christian, >> >> I don't think this affects Encoding Groups - that concept will still >> be in the framework and will need to be expressed in CLUE ADVERTISMENT >> messages, as that's something that isn't well expressible in SDP. The >> encoding limits referred to are the per-encoding limits. >> >> This reflects what we had been taking as our working understanding so >> far in things like the signalling document, so shouldn't involve a >> radical rethink. >> >> Rob >> >> On 02/12/2013 01:04, Christian Groves wrote: >>> Hello Mary, all, >>> >>> In general I'm OK with expressing coding limits in SDP. However I'm >>> trying to understand what the impact is to the CLUE framework as a >>> result of that decision. Does that then mean the entire encoding group >>> concept (i.e. section 8 and 9 (and relevant examples)) are removed from >>> the framework and that a Capture Encoding is now effectively a CaptureID >>> and reference to an SDP m-line? or? >>> >>> Regards, Christian >>> >>> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>>> HI all, >>>> >>>> As mentioned in the email about the November 26th design team meeting, >>>> there was consensus amongst those on the call that SDP should be used >>>> for expressing encoding limits for CLUE. Rob's presentation had >>>> details as to how it could be done using the CLUE protocol, but it was >>>> decided (amongst those on the call) that we should go with the SDP >>>> approach for now and IF an issue is encountered with that approach as >>>> details are worked we could go back to the alternative proposal >>>> outlined in those charts. >>>> >>>> To move forward, we want to ensure that there is WG consensus for >>>> using SDP for the encoding limits. If anyone has any concerns about >>>> that approach, please post a note explaining why no later than Dec >>>> 9th, 2013. If you weren't at the design team meeting and would like >>>> to express your support for the approach, that's also a good idea. >>>> >>>> Regards, >>>> Mary >>>> As WG co-chair >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Tue Dec 3 06:41:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B20B1ADBE5 for ; Tue, 3 Dec 2013 06:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrqZmeOdRNCa for ; Tue, 3 Dec 2013 06:41:34 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A33621ACCEB for ; Tue, 3 Dec 2013 06:41:34 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 3 Dec 2013 06:41:32 -0800 From: "Duckworth, Mark" To: Robert Hansen , "clue@ietf.org" Date: Tue, 3 Dec 2013 06:41:30 -0800 Thread-Topic: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? Thread-Index: Ac7wM36qleM3igVwT66P6yHmsaLx/gAAd2Iw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6046A2BA7@CRPMBOXPRD07.polycom.com> References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <529DE9D1.2030006@cisco.com> In-Reply-To: <529DE9D1.2030006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:41:36 -0000 Just to be clear, a CLUE advertisement can still have encoding groups with = a "max group bandwidth" parameter. But all the individual encoding paramet= ers are in SDP. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen > Sent: Tuesday, December 03, 2013 9:25 AM > To: clue@ietf.org > Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signali= ng? >=20 > Hi Christian, >=20 > That's correct, though the group limits are somewhat orthogonal, and IIRC > we agreed to remove them at IETF87. >=20 > Rob >=20 > On 02/12/2013 22:54, Christian Groves wrote: > > Hello Rob, > > > > So we'll keep the encoding group concept but there will be no CLUE > > encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps > etc)? > > > > Regards, Christian > > > > On 3/12/2013 3:29 AM, Robert Hansen wrote: > >> Hi Christian, > >> > >> I don't think this affects Encoding Groups - that concept will still > >> be in the framework and will need to be expressed in CLUE > >> ADVERTISMENT messages, as that's something that isn't well > >> expressible in SDP. The encoding limits referred to are the per-encodi= ng > limits. > >> > >> This reflects what we had been taking as our working understanding so > >> far in things like the signalling document, so shouldn't involve a > >> radical rethink. > >> > >> Rob > >> > >> On 02/12/2013 01:04, Christian Groves wrote: > >>> Hello Mary, all, > >>> > >>> In general I'm OK with expressing coding limits in SDP. However I'm > >>> trying to understand what the impact is to the CLUE framework as a > >>> result of that decision. Does that then mean the entire encoding > >>> group concept (i.e. section 8 and 9 (and relevant examples)) are > >>> removed from the framework and that a Capture Encoding is now > >>> effectively a CaptureID and reference to an SDP m-line? or? > >>> > >>> Regards, Christian > >>> > >>> On 30/11/2013 8:24 AM, Mary Barnes wrote: > >>>> HI all, > >>>> > >>>> As mentioned in the email about the November 26th design team > >>>> meeting, there was consensus amongst those on the call that SDP > >>>> should be used for expressing encoding limits for CLUE. Rob's > >>>> presentation had details as to how it could be done using the CLUE > >>>> protocol, but it was decided (amongst those on the call) that we > >>>> should go with the SDP approach for now and IF an issue is > >>>> encountered with that approach as details are worked we could go > >>>> back to the alternative proposal outlined in those charts. > >>>> > >>>> To move forward, we want to ensure that there is WG consensus for > >>>> using SDP for the encoding limits. If anyone has any concerns > >>>> about that approach, please post a note explaining why no later than > Dec > >>>> 9th, 2013. If you weren't at the design team meeting and would lik= e > >>>> to express your support for the approach, that's also a good idea. > >>>> > >>>> Regards, > >>>> Mary > >>>> As WG co-chair > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 mary.ietf.barnes@gmail.com Tue Dec 3 07:56:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5433F1AE05B for ; Tue, 3 Dec 2013 07:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0A5stjF6QFC for ; Tue, 3 Dec 2013 07:56:27 -0800 (PST) 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 8F8A01A1F4C for ; Tue, 3 Dec 2013 07:56:27 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so6766445wib.4 for ; Tue, 03 Dec 2013 07:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SFHQlcZ97lIlI/mrq9sOAgMBPrFFg+n1tTyyMLTgIT8=; b=ag7i+JVknQnEXk4xo6p8619jkYbB9TatYeU/Ng8cbutbUmr/6Z8OI9Wz4GopHHfAra nTfgs8GyezBHMM9bgTRbJuZHNgafqE2ZLwYe7K5sR8V4ARN3MXglwZzqaVan2CfEbimO ccjFIQBsnZsGrBA/zqFGVN+3G8LmxNVdwWfDG2BCzfLg9oNeaXevGIUJqoct56YRqlvE nglfjisSSMk4YTllW3Xjv2R912r2oluR+CiGQ3Zj2uApjcoJX1QCanCOf7dTa+3BM52A ZhzhZsrD9gIElOdIwn8AS7vEgLVSpo1q8Qvw345mNpguzBT+i17d2xZTKo840T4LwxVy ONjQ== MIME-Version: 1.0 X-Received: by 10.194.172.105 with SMTP id bb9mr8021037wjc.45.1386086184513; Tue, 03 Dec 2013 07:56:24 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 3 Dec 2013 07:56:24 -0800 (PST) In-Reply-To: <1721875898.6613452.1386085979553.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> References: <1721875898.6613452.1386085979553.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> Date: Tue, 3 Dec 2013 09:56:24 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e012286caa7f79604eca35611 Subject: [clue] Fwd: Doodle: Link for poll "CLUE Design team meeting - Roles" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:56:30 -0000 --089e012286caa7f79604eca35611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As mentioned on the design team call today, Christer (and I) won't be available for the DT call next week. So, we will need to move the data channel discussion to another week. As an alternative, we would like to consider moving the Role discussion to next week (Dec. 10th). =10To ensure we can get Christian on the call to lead the discussion, we would like to switch the time. Note, that I've also included the 17th in the doodle in case we can't get a quorum for the 10th. Please fill out the poll no later than Friday, December 6th at noon CST so that we can get the topic/time confirmed Thanks, Mary. ---------- Forwarded message ---------- From: Doodle Date: Tue, Dec 3, 2013 at 9:52 AM Subject: Doodle: Link for poll "CLUE Design team meeting - Roles" To: Mary Barnes You have initiated a poll "CLUE Design team meeting - Roles" at Doodle. The link to your poll is: http://doodle.com/u3894ty7xkkcfbse Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) --089e012286caa7f79604eca35611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As mentioned on the design team call today, Christer (and = I) won't be available for the DT call next week. =A0So, we will need to= move the data channel discussion to another week. =A0As an alternative, we= would like to consider moving the Role discussion to next week (Dec. 10th)= . =A0=10To ensure we can get Christian on the call to lead the discussion, = we would like to switch the time. =A0Note, that I've also included the = 17th in the doodle in case we can't get a quorum for the 10th.=A0

Please fill out the poll no later than Friday, December 6th = at noon CST so that we can get the topic/time confirmed

Thanks,
Mary.=A0

--------= -- Forwarded message ----------
From: Doodle <mailer@doodle.com>
Date: Tu= e, Dec 3, 2013 at 9:52 AM
Subject: Doodle: Link for poll "CLUE Desi= gn team meeting - Roles"
To: Mary Barnes <mary.ietf= .barnes@gmail.com>


You have initiated a poll "CLUE D= esign team meeting - Roles" at Doodle. The link to your poll is:

http://doo= dle.com/u3894ty7xkkcfbse

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)

--089e012286caa7f79604eca35611-- From Christian.Groves@nteczone.com Tue Dec 3 14:50:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98261AE199 for ; Tue, 3 Dec 2013 14:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6soGwNXsMbOu for ; Tue, 3 Dec 2013 14:50:36 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E151AE192 for ; Tue, 3 Dec 2013 14:50:35 -0800 (PST) Received: from ppp118-209-19-52.lns20.mel4.internode.on.net ([118.209.19.52]:52535 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VnymR-0002j0-Du; Wed, 04 Dec 2013 09:49:23 +1100 Message-ID: <529E6034.8010009@nteczone.com> Date: Wed, 04 Dec 2013 09:50:28 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 22:50:37 -0000 Hello Mark, I guess what I found confusing is that the decision was with regards to "Encoding Limits" (i.e. maximums) not encoding parameters which I agree we've previously thought as being in SDP. The examples in the framework also shows maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth against individual encodes. So the framework isn't consistent on this. Regards, Christian On 4/12/2013 1:17 AM, Duckworth, Mark wrote: > Hello Christian, > > I agree with Rob, and even further, I think the Framework document is already consistent with this approach, because it has been our working understanding for quite a while. > > This text from section 8.1 sums it up nicely: > "Individual Encoding parameters are represented in SDP [RFC4566], > not in CLUE messages. For example, for a video encoding using > H.26x compression technologies, this can include parameters such > as: > . Maximum bandwidth; > . Maximum picture size in pixels; > . Maximum number of pixels to be processed per second; > The bandwidth parameter is the only one that specifically relates > to a CLUE Advertisement, as it can be further constrained by the > maximum group bandwidth in an Encoding Group." > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Monday, December 02, 2013 5:55 PM >> To: clue@ietf.org >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? >> >> Hello Rob, >> >> So we'll keep the encoding group concept but there will be no CLUE encoding >> parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps etc)? >> >> Regards, Christian >> >> On 3/12/2013 3:29 AM, Robert Hansen wrote: >>> Hi Christian, >>> >>> I don't think this affects Encoding Groups - that concept will still >>> be in the framework and will need to be expressed in CLUE ADVERTISMENT >>> messages, as that's something that isn't well expressible in SDP. The >>> encoding limits referred to are the per-encoding limits. >>> >>> This reflects what we had been taking as our working understanding so >>> far in things like the signalling document, so shouldn't involve a >>> radical rethink. >>> >>> Rob >>> >>> On 02/12/2013 01:04, Christian Groves wrote: >>>> Hello Mary, all, >>>> >>>> In general I'm OK with expressing coding limits in SDP. However I'm >>>> trying to understand what the impact is to the CLUE framework as a >>>> result of that decision. Does that then mean the entire encoding >>>> group concept (i.e. section 8 and 9 (and relevant examples)) are >>>> removed from the framework and that a Capture Encoding is now >>>> effectively a CaptureID and reference to an SDP m-line? or? >>>> >>>> Regards, Christian >>>> >>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>>>> HI all, >>>>> >>>>> As mentioned in the email about the November 26th design team >>>>> meeting, there was consensus amongst those on the call that SDP >>>>> should be used for expressing encoding limits for CLUE. Rob's >>>>> presentation had details as to how it could be done using the CLUE >>>>> protocol, but it was decided (amongst those on the call) that we >>>>> should go with the SDP approach for now and IF an issue is >>>>> encountered with that approach as details are worked we could go >>>>> back to the alternative proposal outlined in those charts. >>>>> >>>>> To move forward, we want to ensure that there is WG consensus for >>>>> using SDP for the encoding limits. If anyone has any concerns about >>>>> that approach, please post a note explaining why no later than Dec >>>>> 9th, 2013. If you weren't at the design team meeting and would like >>>>> to express your support for the approach, that's also a good idea. >>>>> >>>>> Regards, >>>>> Mary >>>>> As WG co-chair >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Dec 3 15:02:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C021AE1C9 for ; Tue, 3 Dec 2013 15:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcmZAhJMoTkz for ; Tue, 3 Dec 2013 15:02:17 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B211AE1C6 for ; Tue, 3 Dec 2013 15:02:17 -0800 (PST) Received: from ppp118-209-19-52.lns20.mel4.internode.on.net ([118.209.19.52]:52798 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1Vnyxl-0004fL-I8 for clue@ietf.org; Wed, 04 Dec 2013 10:01:05 +1100 Message-ID: <529E62F2.7090101@nteczone.com> Date: Wed, 04 Dec 2013 10:02:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> In-Reply-To: <5292A5CE.4050605@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:02:20 -0000 Hello all, Does anyone have any more concerns or comments about the "roles" work? It would be good to get your comments as soon as possible so that I could either address then via the list or prepare slides for next week's design team meeting to address them. Regards, Christian On 25/11/2013 12:20 PM, Christian Groves wrote: > Hello all, > > I'd like to pick up the discussion on roles from the last CLUE WG > meeting and try and make some progress via email before the design > team meeting. > > First i'd like to clarify that "role" is not intended to be a single > attribute and it can have different meanings. My draft > (draft-groves-clue-role-clarifications-00) seeks to clarify and > provide a terminology to be more specific. I.e.: > 2.1. Meeting Roles > 2.2. Conference System Control Roles > 2.3. Institution type > 2.4. Person Name Title > 2.5. Person Occupation (Job Title) > 2.6. Organisation Name > 2.7. Meeting Specific Roles > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the > draft. 2.1 and 2.7 have also been grouped by the draft. > > There has been some concern that "roles" overlap with floor control. > From the role categories above I believe this is only relevant for > "conference system control" roles. > > Secondly the intended purpose of including "roles" into CLUE is not > for conference control or rostering but is for the selection of > Scenes/Captures and may be used for any subsequent rendering decisions > like the other CLUE attributes. The focus of the CLUE work has been to > focus on selecting captures based on technical aspects (what) e.g. > spatial properties but I think we've missed a more important aspect > that captures will depict people or entities (who). As a consumer I'm > likely to be more interested in who rather than what. For example if I > have a limited system and have received an Advertisement advertising 3 > Captures(left/centre/right) and I have only one screen so must choose > one. One could choose the centre but this is a problem if my boss is > sitting in the left capture. > > Thirdly because CLUE enhances the support of multiple streams there is > likely to be a larger set of captures being advertised. Information > about sources scenes/captures including different combinations may be > sent to a consumer providing much more choice. Each of these > scenes/captures may have different role information. Rather than try > to implement role across several different methods and introduce > dependencies between CLUE and other methods (e.g. conference package > or SDP which have no Scene/capture/MCC concepts) it is most > straightforward to send the information where it is needed i.e. in CLUE. > > Fourthly we have included the "description" parameter at the Scene,CSE > and Capture level. I think people will use those as de-facto for > "role" type information e.g. Scene Description="Company X VIC meeting > room". Rather than have a completely unstructured usage of description > I think that having "role" type information provided in a structured > form (i.e. via vCard) will at least provide a consumer the ability to > do some intelligent processing/rendering of the information. By > allowing this "role" information to be sent in a structured way via > CLUE I think will be an enabler for some interesting services and > features. > > Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. > > Comments? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From roni.even@mail01.huawei.com Wed Dec 4 05:21:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5E71AE24B for ; Wed, 4 Dec 2013 05:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l_XoGJU4IU4T for ; Wed, 4 Dec 2013 05:21:27 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id C8C931AE224 for ; Wed, 4 Dec 2013 05:21:26 -0800 (PST) Received: from 172.24.1.78 (EHLO szxpml201-edg.exmail.huawei.com) ([172.24.1.78]) by szxrg12-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUB76805; Wed, 04 Dec 2013 21:21:22 +0800 (CST) From: Roni Even To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Roles Thread-Index: AQHO6XyOnMHOQNKf/UaL03Tk1oLVyppCnk4AgAFwPMM= Date: Wed, 4 Dec 2013 13:21:15 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C23E548DBF@szxpml507-mbs.exmail.huawei.com> References: <5292A5CE.4050605@nteczone.com>,<529E62F2.7090101@nteczone.com> In-Reply-To: <529E62F2.7090101@nteczone.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 13:21:31 -0000 Hi, I would like to get clarfication only about the proposal, i think this will= help us adopt this proposal. Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. Are the meeting roles in section 3.1 enumareted value or free text (for hum= an or machine selection?). If for machine selection, is there a priority se= lection order (pre defined preference) or is it left to each aplication dec= ision. Is the behavior of the consumer different between 3.1 and 3.2? > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. Are these values to be enumarted or just text. are they used by the system = or just diaplayed by the application. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. How do you see the linkage between a vCard and specfic person in a capture? > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. Roni ________________________________________ From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian= .Groves@nteczone.com] Sent: Wednesday, December 04, 2013 1:02 AM To: clue@ietf.org Subject: Re: [clue] Roles Hello all, Does anyone have any more concerns or comments about the "roles" work? It would be good to get your comments as soon as possible so that I could either address then via the list or prepare slides for next week's design team meeting to address them. Regards, Christian On 25/11/2013 12:20 PM, Christian Groves wrote: > Hello all, > > I'd like to pick up the discussion on roles from the last CLUE WG > meeting and try and make some progress via email before the design > team meeting. > > First i'd like to clarify that "role" is not intended to be a single > attribute and it can have different meanings. My draft > (draft-groves-clue-role-clarifications-00) seeks to clarify and > provide a terminology to be more specific. I.e.: > 2.1. Meeting Roles > 2.2. Conference System Control Roles > 2.3. Institution type > 2.4. Person Name Title > 2.5. Person Occupation (Job Title) > 2.6. Organisation Name > 2.7. Meeting Specific Roles > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the > draft. 2.1 and 2.7 have also been grouped by the draft. > > There has been some concern that "roles" overlap with floor control. > From the role categories above I believe this is only relevant for > "conference system control" roles. > > Secondly the intended purpose of including "roles" into CLUE is not > for conference control or rostering but is for the selection of > Scenes/Captures and may be used for any subsequent rendering decisions > like the other CLUE attributes. The focus of the CLUE work has been to > focus on selecting captures based on technical aspects (what) e.g. > spatial properties but I think we've missed a more important aspect > that captures will depict people or entities (who). As a consumer I'm > likely to be more interested in who rather than what. For example if I > have a limited system and have received an Advertisement advertising 3 > Captures(left/centre/right) and I have only one screen so must choose > one. One could choose the centre but this is a problem if my boss is > sitting in the left capture. > > Thirdly because CLUE enhances the support of multiple streams there is > likely to be a larger set of captures being advertised. Information > about sources scenes/captures including different combinations may be > sent to a consumer providing much more choice. Each of these > scenes/captures may have different role information. Rather than try > to implement role across several different methods and introduce > dependencies between CLUE and other methods (e.g. conference package > or SDP which have no Scene/capture/MCC concepts) it is most > straightforward to send the information where it is needed i.e. in CLUE. > > Fourthly we have included the "description" parameter at the Scene,CSE > and Capture level. I think people will use those as de-facto for > "role" type information e.g. Scene Description=3D"Company X VIC meeting > room". Rather than have a completely unstructured usage of description > I think that having "role" type information provided in a structured > form (i.e. via vCard) will at least provide a consumer the ability to > do some intelligent processing/rendering of the information. By > allowing this "role" information to be sent in a structured way via > CLUE I think will be an enabler for some interesting services and > features. > > Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. > > Comments? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Dec 4 09:38:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6BB1AE193 for ; Wed, 4 Dec 2013 09:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqtnvgFLIBzN for ; Wed, 4 Dec 2013 09:38:42 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 576521AE160 for ; Wed, 4 Dec 2013 09:38:42 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 4 Dec 2013 09:15:45 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 4 Dec 2013 09:15:42 -0800 Thread-Topic: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? Thread-Index: Ac7weheo1MyHqoCfRj62OF0aDtPREgAeRsWA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> In-Reply-To: <529E6034.8010009@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:38:45 -0000 Hi Christian, Maybe there is confusion about "encoding limits" vs. "encoding parameters".= I think we have been talking about "limits" and "parameters" as being the= same thing. Here is my understanding. A CLUE encoding has "encoding limi= ts" (see draft-ietf-clue-framework-12 section 8.1 and draft-kyzivat-clue-si= gnaling-05 section 4.2). For the sender (encoder side), these are expresse= d in SDP (a=3Dsendonly), and referenced in a CLUE advertisement. Similarly= , for the receiver (decoder side) the limits are expressed in SDP (a=3Drecv= only) and referenced in a CLUE configure message. Framework section 8.1 mentions the possibility of the codec actually using = lower values for some of these parameters, and gives example of how certain= parameters for certain codecs can be considered limits with possibility of= using lower values. It seems to me that in general this isn't CLUE specif= ic. This is just how these parameters are meant to be used in SDP offer/an= swer (and maybe also in H.323 protocol?). CLUE isn't trying to change this= , it is just adding the ability to reference these existing codec parameter= s in CLUE messages. I disagree with you about the consistency of the framework examples. The "= maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters you mention= ed are all still part of the framework. Whether they are expressed directl= y in CLUE messages or references to SDP is not relevant to these examples. = If we eventually add more examples (in the signaling document?) for CLUE p= rotocol and/or using the data model, then these lower level details should = appear in those examples. Regards, Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, December 03, 2013 5:50 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signali= ng? >=20 > Hello Mark, >=20 > I guess what I found confusing is that the decision was with regards to > "Encoding Limits" (i.e. maximums) not encoding parameters which I agree > we've previously thought as being in SDP. The examples in the framework > also shows maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth > against individual encodes. So the framework isn't consistent on this. >=20 > Regards, Christian >=20 > On 4/12/2013 1:17 AM, Duckworth, Mark wrote: > > Hello Christian, > > > > I agree with Rob, and even further, I think the Framework document is > already consistent with this approach, because it has been our working > understanding for quite a while. > > > > This text from section 8.1 sums it up nicely: > > "Individual Encoding parameters are represented in SDP [RFC4566], > > not in CLUE messages. For example, for a video encoding using > > H.26x compression technologies, this can include parameters such > > as: > > . Maximum bandwidth; > > . Maximum picture size in pixels; > > . Maximum number of pixels to be processed per second; > > The bandwidth parameter is the only one that specifically relates > > to a CLUE Advertisement, as it can be further constrained by the > > maximum group bandwidth in an Encoding Group." > > > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >> Groves > >> Sent: Monday, December 02, 2013 5:55 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE sign= aling? > >> > >> Hello Rob, > >> > >> So we'll keep the encoding group concept but there will be no CLUE > >> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps > etc)? > >> > >> Regards, Christian > >> > >> On 3/12/2013 3:29 AM, Robert Hansen wrote: > >>> Hi Christian, > >>> > >>> I don't think this affects Encoding Groups - that concept will still > >>> be in the framework and will need to be expressed in CLUE > >>> ADVERTISMENT messages, as that's something that isn't well > >>> expressible in SDP. The encoding limits referred to are the per-encod= ing > limits. > >>> > >>> This reflects what we had been taking as our working understanding > >>> so far in things like the signalling document, so shouldn't involve > >>> a radical rethink. > >>> > >>> Rob > >>> > >>> On 02/12/2013 01:04, Christian Groves wrote: > >>>> Hello Mary, all, > >>>> > >>>> In general I'm OK with expressing coding limits in SDP. However I'm > >>>> trying to understand what the impact is to the CLUE framework as a > >>>> result of that decision. Does that then mean the entire encoding > >>>> group concept (i.e. section 8 and 9 (and relevant examples)) are > >>>> removed from the framework and that a Capture Encoding is now > >>>> effectively a CaptureID and reference to an SDP m-line? or? > >>>> > >>>> Regards, Christian > >>>> > >>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: > >>>>> HI all, > >>>>> > >>>>> As mentioned in the email about the November 26th design team > >>>>> meeting, there was consensus amongst those on the call that SDP > >>>>> should be used for expressing encoding limits for CLUE. Rob's > >>>>> presentation had details as to how it could be done using the CLUE > >>>>> protocol, but it was decided (amongst those on the call) that we > >>>>> should go with the SDP approach for now and IF an issue is > >>>>> encountered with that approach as details are worked we could go > >>>>> back to the alternative proposal outlined in those charts. > >>>>> > >>>>> To move forward, we want to ensure that there is WG consensus for > >>>>> using SDP for the encoding limits. If anyone has any concerns > >>>>> about that approach, please post a note explaining why no later tha= n > Dec > >>>>> 9th, 2013. If you weren't at the design team meeting and would li= ke > >>>>> to express your support for the approach, that's also a good idea. > >>>>> > >>>>> Regards, > >>>>> Mary > >>>>> As WG co-chair > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Dec 4 15:10:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03E41AE2D8 for ; Wed, 4 Dec 2013 15:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHtGRDKwnnHG for ; Wed, 4 Dec 2013 15:10:00 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 495FC1AE22C for ; Wed, 4 Dec 2013 15:10:00 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 4 Dec 2013 15:09:56 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 4 Dec 2013 15:09:54 -0800 Thread-Topic: [clue] Roles Thread-Index: Ac7we7qbX9cgraxoQgiM+2aZwUDNfgAyKp0w Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6048B26E6@CRPMBOXPRD07.polycom.com> References: <5292A5CE.4050605@nteczone.com> <529E62F2.7090101@nteczone.com> In-Reply-To: <529E62F2.7090101@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:10:03 -0000 Hi Christian, I understand the reasoning you give for why these role attributes have valu= e. But I don't see a strong reason why they are necessary for CLUE. I'm c= oncerned it will distract us from more essential work. I don't understand the difference between the proposal for a "vCard" attrib= ute and the "End point vCard" attribute. Can you explain? Regarding vCard, have you thought about the impact to the CLUE data model a= nd protocol? I skimmed through RFC6350, and as I understand it the vCard f= ormat is all UTF-8 text, but not XML. And it can be very large, particular= ly if it includes embedded audio and photographs. I wonder if this potenti= ally large non-XML data will cause problems if we add it to a CLUE advertis= ement message. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, December 03, 2013 6:02 PM > To: clue@ietf.org > Subject: Re: [clue] Roles >=20 > Hello all, >=20 > Does anyone have any more concerns or comments about the "roles" work? >=20 > It would be good to get your comments as soon as possible so that I could > either address then via the list or prepare slides for next week's design= team > meeting to address them. >=20 > Regards, Christian >=20 > On 25/11/2013 12:20 PM, Christian Groves wrote: > > Hello all, > > > > I'd like to pick up the discussion on roles from the last CLUE WG > > meeting and try and make some progress via email before the design > > team meeting. > > > > First i'd like to clarify that "role" is not intended to be a single > > attribute and it can have different meanings. My draft > > (draft-groves-clue-role-clarifications-00) seeks to clarify and > > provide a terminology to be more specific. I.e.: > > 2.1. Meeting Roles > > 2.2. Conference System Control Roles > > 2.3. Institution type > > 2.4. Person Name Title > > 2.5. Person Occupation (Job Title) > > 2.6. Organisation Name > > 2.7. Meeting Specific Roles > > > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the > > draft. 2.1 and 2.7 have also been grouped by the draft. > > > > There has been some concern that "roles" overlap with floor control. > > From the role categories above I believe this is only relevant for > > "conference system control" roles. > > > > Secondly the intended purpose of including "roles" into CLUE is not > > for conference control or rostering but is for the selection of > > Scenes/Captures and may be used for any subsequent rendering decisions > > like the other CLUE attributes. The focus of the CLUE work has been to > > focus on selecting captures based on technical aspects (what) e.g. > > spatial properties but I think we've missed a more important aspect > > that captures will depict people or entities (who). As a consumer I'm > > likely to be more interested in who rather than what. For example if I > > have a limited system and have received an Advertisement advertising 3 > > Captures(left/centre/right) and I have only one screen so must choose > > one. One could choose the centre but this is a problem if my boss is > > sitting in the left capture. > > > > Thirdly because CLUE enhances the support of multiple streams there is > > likely to be a larger set of captures being advertised. Information > > about sources scenes/captures including different combinations may be > > sent to a consumer providing much more choice. Each of these > > scenes/captures may have different role information. Rather than try > > to implement role across several different methods and introduce > > dependencies between CLUE and other methods (e.g. conference package > > or SDP which have no Scene/capture/MCC concepts) it is most > > straightforward to send the information where it is needed i.e. in CLUE= . > > > > Fourthly we have included the "description" parameter at the Scene,CSE > > and Capture level. I think people will use those as de-facto for > > "role" type information e.g. Scene Description=3D"Company X VIC meeting > > room". Rather than have a completely unstructured usage of description > > I think that having "role" type information provided in a structured > > form (i.e. via vCard) will at least provide a consumer the ability to > > do some intelligent processing/rendering of the information. By > > allowing this "role" information to be sent in a structured way via > > CLUE I think will be an enabler for some interesting services and > > features. > > > > Finally to re-iterate what the proposal is from the draft: > > 1. The addition of a capture attribute "Meeting Role" attribute > > with values as per section 3.1 and 3.2. > > 2. The addition of a capture attribute "Conference System > > Control Role" attribute with values as per section 3.3. > > 3. The addition of a capture attribute "vCard" that allows one > > or more vCards according to [RFC6350] to be associated with a > > capture. > > 4. The addition of a capture attribute "End point vCard" that > > allows a "group", "org" or "location" kind of vCard according > > to section 6.1.4/[RFC6350] to be associated with a capture. > > > > Comments? > > > > Regards, Christian > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Dec 4 15:43:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AF21ADF66 for ; Wed, 4 Dec 2013 15:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUbMdfURfW73 for ; Wed, 4 Dec 2013 15:43:16 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0431AD948 for ; Wed, 4 Dec 2013 15:43:16 -0800 (PST) Received: from ppp118-209-3-225.lns20.mel4.internode.on.net ([118.209.3.225]:51949 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VoM4j-0005aU-9v; Thu, 05 Dec 2013 10:41:49 +1100 Message-ID: <529FBE0C.5080606@nteczone.com> Date: Thu, 05 Dec 2013 10:43:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:43:19 -0000 Hello Mark, Please see my response below. Regards, Christian On 5/12/2013 4:15 AM, Duckworth, Mark wrote: > Hi Christian, > > Maybe there is confusion about "encoding limits" vs. "encoding parameters". I think we have been talking about "limits" and "parameters" as being the same thing. Here is my understanding. A CLUE encoding has "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and draft-kyzivat-clue-signaling-05 section 4.2). For the sender (encoder side), these are expressed in SDP (a=sendonly), and referenced in a CLUE advertisement. Similarly, for the receiver (decoder side) the limits are expressed in SDP (a=recvonly) and referenced in a CLUE configure message. [CNG] This is where I'm confused. You say CLUE has "encoding limits" but the decision is that SDP has the encoding limits. I would say CLUE references an encoding defined by SDP. It is up to SDP to define that encoding in whatever way. I.e. it may have a specific encoding and/or may also have attributes that define limits. CLUE groups the encodings. > > Framework section 8.1 mentions the possibility of the codec actually using lower values for some of these parameters, and gives example of how certain parameters for certain codecs can be considered limits with possibility of using lower values. It seems to me that in general this isn't CLUE specific. This is just how these parameters are meant to be used in SDP offer/answer (and maybe also in H.323 protocol?). CLUE isn't trying to change this, it is just adding the ability to reference these existing codec parameters in CLUE messages. [CNG] OK this is another thing I didn't understand from the proposal. Again I thought we just reference the SDP encoding, not the individual SDP parameters in the CLUE messages? > > I disagree with you about the consistency of the framework examples. The "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters you mentioned are all still part of the framework. Whether they are expressed directly in CLUE messages or references to SDP is not relevant to these examples. If we eventually add more examples (in the signaling document?) for CLUE protocol and/or using the data model, then these lower level details should appear in those examples. [CNG] I think the issue is that the start of the text of section 8.1 and the examples was when the encoding parameters were present in CLUE itself. If we now say SDP contains the encoding information its not up to CLUE to say how these SDP parameters are interpreted. i.e. section 8.1 says "The parameters of an Individual Encoding represent the maximum values for certain aspects of the encoding." This is not the case for all SDP parameters/attributes. What they represent is up to the semantics of the SDP parameter itself. Also when I look at the example it certainly implies that the parameters are part of CLUE i.e. associated with the encoding rather than CLUE referencing an encoding defined elsewhere. E.g. CLUE has: encodeGroupID=EG0, maxGroupBandwidth=6000000 encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, maxPps=124416000, maxBandwidth=4000000 encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, maxPps=27648000, maxBandwidth=4000000 encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, maxPps=15552000, maxBandwidth=4000000 Which to me at least implies they are all part of the same syntax definition. Whereas to show that the parameters are defined outside CLUE I would expect something like: Encoding Groups: encodeGroupID=EG0, maxGroupBandwidth=6000000 encodeID=ENC0 encodeID=ENC1 encodeID=ENC2 Encodings: m=video label=ENC0 a=maxWidth:1920 a=maxHeight:1088 ... m=video label=ENC1 a=maxWidth:1280 a=maxHeight:720 ... etc. The above SDP isn't correct but I'm just try to illustrate that it would be good to show the define of the parameters separate from the definition of the encoding groups. It could be abstracted not to have SDP. > > Regards, > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Tuesday, December 03, 2013 5:50 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? >> >> Hello Mark, >> >> I guess what I found confusing is that the decision was with regards to >> "Encoding Limits" (i.e. maximums) not encoding parameters which I agree >> we've previously thought as being in SDP. The examples in the framework >> also shows maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth >> against individual encodes. So the framework isn't consistent on this. >> >> Regards, Christian >> >> On 4/12/2013 1:17 AM, Duckworth, Mark wrote: >>> Hello Christian, >>> >>> I agree with Rob, and even further, I think the Framework document is >> already consistent with this approach, because it has been our working >> understanding for quite a while. >>> This text from section 8.1 sums it up nicely: >>> "Individual Encoding parameters are represented in SDP [RFC4566], >>> not in CLUE messages. For example, for a video encoding using >>> H.26x compression technologies, this can include parameters such >>> as: >>> . Maximum bandwidth; >>> . Maximum picture size in pixels; >>> . Maximum number of pixels to be processed per second; >>> The bandwidth parameter is the only one that specifically relates >>> to a CLUE Advertisement, as it can be further constrained by the >>> maximum group bandwidth in an Encoding Group." >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>> Groves >>>> Sent: Monday, December 02, 2013 5:55 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? >>>> >>>> Hello Rob, >>>> >>>> So we'll keep the encoding group concept but there will be no CLUE >>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps >> etc)? >>>> Regards, Christian >>>> >>>> On 3/12/2013 3:29 AM, Robert Hansen wrote: >>>>> Hi Christian, >>>>> >>>>> I don't think this affects Encoding Groups - that concept will still >>>>> be in the framework and will need to be expressed in CLUE >>>>> ADVERTISMENT messages, as that's something that isn't well >>>>> expressible in SDP. The encoding limits referred to are the per-encoding >> limits. >>>>> This reflects what we had been taking as our working understanding >>>>> so far in things like the signalling document, so shouldn't involve >>>>> a radical rethink. >>>>> >>>>> Rob >>>>> >>>>> On 02/12/2013 01:04, Christian Groves wrote: >>>>>> Hello Mary, all, >>>>>> >>>>>> In general I'm OK with expressing coding limits in SDP. However I'm >>>>>> trying to understand what the impact is to the CLUE framework as a >>>>>> result of that decision. Does that then mean the entire encoding >>>>>> group concept (i.e. section 8 and 9 (and relevant examples)) are >>>>>> removed from the framework and that a Capture Encoding is now >>>>>> effectively a CaptureID and reference to an SDP m-line? or? >>>>>> >>>>>> Regards, Christian >>>>>> >>>>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>>>>>> HI all, >>>>>>> >>>>>>> As mentioned in the email about the November 26th design team >>>>>>> meeting, there was consensus amongst those on the call that SDP >>>>>>> should be used for expressing encoding limits for CLUE. Rob's >>>>>>> presentation had details as to how it could be done using the CLUE >>>>>>> protocol, but it was decided (amongst those on the call) that we >>>>>>> should go with the SDP approach for now and IF an issue is >>>>>>> encountered with that approach as details are worked we could go >>>>>>> back to the alternative proposal outlined in those charts. >>>>>>> >>>>>>> To move forward, we want to ensure that there is WG consensus for >>>>>>> using SDP for the encoding limits. If anyone has any concerns >>>>>>> about that approach, please post a note explaining why no later than >> Dec >>>>>>> 9th, 2013. If you weren't at the design team meeting and would like >>>>>>> to express your support for the approach, that's also a good idea. >>>>>>> >>>>>>> Regards, >>>>>>> Mary >>>>>>> As WG co-chair >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed Dec 4 16:04:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F391ADFBD for ; Wed, 4 Dec 2013 16:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1G5yjs0pEtn for ; Wed, 4 Dec 2013 16:04:05 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6251AE1D7 for ; Wed, 4 Dec 2013 16:04:05 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 4 Dec 2013 16:04:01 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 4 Dec 2013 16:03:59 -0800 Thread-Topic: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? Thread-Index: Ac7xSp5bCys4s25QTO+xpQtenechpgAAJQmA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6048B2703@CRPMBOXPRD07.polycom.com> References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> <529FBE0C.5080606@nteczone.com> In-Reply-To: <529FBE0C.5080606@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:04:08 -0000 Hi Christian, I think we have same understanding about the concept, but are having troubl= e with terminology. In any case, I think we are both agreeing on using SDP= to express encoding limits, but are now discussing possible impact to the = framework document. Comments inline. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Wednesday, December 04, 2013 6:43 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signali= ng? >=20 > Hello Mark, >=20 > Please see my response below. >=20 > Regards, Christian >=20 > On 5/12/2013 4:15 AM, Duckworth, Mark wrote: > > Hi Christian, > > > > Maybe there is confusion about "encoding limits" vs. "encoding > parameters". I think we have been talking about "limits" and "parameters= " > as being the same thing. Here is my understanding. A CLUE encoding has > "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and draft= - > kyzivat-clue-signaling-05 section 4.2). For the sender (encoder side), t= hese > are expressed in SDP (a=3Dsendonly), and referenced in a CLUE advertiseme= nt. > Similarly, for the receiver (decoder side) the limits are expressed in SD= P > (a=3Drecvonly) and referenced in a CLUE configure message. > [CNG] This is where I'm confused. You say CLUE has "encoding limits" but = the > decision is that SDP has the encoding limits. I would say CLUE references= an > encoding defined by SDP. It is up to SDP to define that encoding in whate= ver > way. I.e. it may have a specific encoding and/or may also have attributes= that > define limits. CLUE groups the encodings. [Duckworth, Mark] Sorry, I wasn't clear. I meant the CLUE framework includ= es encoding limits. A CLUE encoding has encoding limits. These encoding = limits are expressed in SDP and referenced by CLUE protocol messages. Does= that make more sense? > > Framework section 8.1 mentions the possibility of the codec actually us= ing > lower values for some of these parameters, and gives example of how > certain parameters for certain codecs can be considered limits with possi= bility > of using lower values. It seems to me that in general this isn't CLUE sp= ecific. > This is just how these parameters are meant to be used in SDP offer/answe= r > (and maybe also in H.323 protocol?). CLUE isn't trying to change this, i= t is just > adding the ability to reference these existing codec parameters in CLUE > messages. > [CNG] OK this is another thing I didn't understand from the proposal. > Again I thought we just reference the SDP encoding, not the individual SD= P > parameters in the CLUE messages? [Duckworth, Mark] I didn't mean there are references to individual paramete= rs. I think your first idea is correct, a CLUE message associates a CLUE e= ncoding with an SDP m-line and other information in SDP included with the m= -line, and this includes the encoding parameters. > > I disagree with you about the consistency of the framework examples. T= he > "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters > you mentioned are all still part of the framework. Whether they are > expressed directly in CLUE messages or references to SDP is not relevant = to > these examples. If we eventually add more examples (in the signaling > document?) for CLUE protocol and/or using the data model, then these > lower level details should appear in those examples. > [CNG] I think the issue is that the start of the text of section 8.1 and = the > examples was when the encoding parameters were present in CLUE itself. If > we now say SDP contains the encoding information its not up to CLUE to sa= y > how these SDP parameters are interpreted. i.e. section > 8.1 says "The parameters of an Individual Encoding represent the maximum > values for certain aspects of the encoding." This is not the case for all= SDP > parameters/attributes. What they represent is up to the semantics of the > SDP parameter itself. [Duckworth, Mark] Okay, I understand that. Further down in section 8.1 I t= hink it explains it better, but maybe we can clean it up further. > Also when I look at the example it certainly implies that the parameters = are > part of CLUE i.e. associated with the encoding rather than CLUE referenci= ng > an encoding defined elsewhere. > E.g. CLUE has: > encodeGroupID=3DEG0, maxGroupBandwidth=3D6000000 > encodeID=3DENC0, maxWidth=3D1920, maxHeight=3D1088, maxFrameRate= =3D60, > maxPps=3D124416000, maxBandwidth=3D4000000 > encodeID=3DENC1, maxWidth=3D1280, maxHeight=3D720, maxFrameRate= =3D30, > maxPps=3D27648000, maxBandwidth=3D4000000 > encodeID=3DENC2, maxWidth=3D960, maxHeight=3D544, maxFrameRate=3D= 30, > maxPps=3D15552000, maxBandwidth=3D4000000 >=20 > Which to me at least implies they are all part of the same syntax definit= ion. >=20 > Whereas to show that the parameters are defined outside CLUE I would > expect something like: > Encoding Groups: > encodeGroupID=3DEG0, maxGroupBandwidth=3D6000000 > encodeID=3DENC0 > encodeID=3DENC1 > encodeID=3DENC2 >=20 > Encodings: > m=3Dvideo > label=3DENC0 > a=3DmaxWidth:1920 > a=3DmaxHeight:1088 > ... > m=3Dvideo > label=3DENC1 > a=3DmaxWidth:1280 > a=3DmaxHeight:720 > ... > etc. >=20 > The above SDP isn't correct but I'm just try to illustrate that it would = be good > to show the define of the parameters separate from the definition of the > encoding groups. It could be abstracted not to have SDP. [Duckworth, Mark] I understand. I guess it depends on how much "syntax det= ail" you want to show in the examples, even though it isn't really proper C= LUE data model or protocol or SDP syntax at all. My view is the example is= okay as is, without adding more syntax detail. I thought the working grou= p agreed in general these framework examples should be fairly high level an= d not get bogged down in syntax. [Duckworth, Mark] Does anybody else have input about this? > > Regards, > > Mark > > > >> -----Original Message----- > >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] > >> Sent: Tuesday, December 03, 2013 5:50 PM > >> To: Duckworth, Mark; clue@ietf.org > >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE sign= aling? > >> > >> Hello Mark, > >> > >> I guess what I found confusing is that the decision was with regards > >> to "Encoding Limits" (i.e. maximums) not encoding parameters which I > >> agree we've previously thought as being in SDP. The examples in the > >> framework also shows > >> maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth > >> against individual encodes. So the framework isn't consistent on this. > >> > >> Regards, Christian > >> > >> On 4/12/2013 1:17 AM, Duckworth, Mark wrote: > >>> Hello Christian, > >>> > >>> I agree with Rob, and even further, I think the Framework document > >>> is > >> already consistent with this approach, because it has been our > >> working understanding for quite a while. > >>> This text from section 8.1 sums it up nicely: > >>> "Individual Encoding parameters are represented in SDP [RFC4566= ], > >>> not in CLUE messages. For example, for a video encoding using > >>> H.26x compression technologies, this can include parameters suc= h > >>> as: > >>> . Maximum bandwidth; > >>> . Maximum picture size in pixels; > >>> . Maximum number of pixels to be processed per second; > >>> The bandwidth parameter is the only one that specifically relat= es > >>> to a CLUE Advertisement, as it can be further constrained by th= e > >>> maximum group bandwidth in an Encoding Group." > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>>> Groves > >>>> Sent: Monday, December 02, 2013 5:55 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE > signaling? > >>>> > >>>> Hello Rob, > >>>> > >>>> So we'll keep the encoding group concept but there will be no CLUE > >>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps > >> etc)? > >>>> Regards, Christian > >>>> > >>>> On 3/12/2013 3:29 AM, Robert Hansen wrote: > >>>>> Hi Christian, > >>>>> > >>>>> I don't think this affects Encoding Groups - that concept will > >>>>> still be in the framework and will need to be expressed in CLUE > >>>>> ADVERTISMENT messages, as that's something that isn't well > >>>>> expressible in SDP. The encoding limits referred to are the > >>>>> per-encoding > >> limits. > >>>>> This reflects what we had been taking as our working understanding > >>>>> so far in things like the signalling document, so shouldn't > >>>>> involve a radical rethink. > >>>>> > >>>>> Rob > >>>>> > >>>>> On 02/12/2013 01:04, Christian Groves wrote: > >>>>>> Hello Mary, all, > >>>>>> > >>>>>> In general I'm OK with expressing coding limits in SDP. However > >>>>>> I'm trying to understand what the impact is to the CLUE framework > >>>>>> as a result of that decision. Does that then mean the entire > >>>>>> encoding group concept (i.e. section 8 and 9 (and relevant > >>>>>> examples)) are removed from the framework and that a Capture > >>>>>> Encoding is now effectively a CaptureID and reference to an SDP m- > line? or? > >>>>>> > >>>>>> Regards, Christian > >>>>>> > >>>>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: > >>>>>>> HI all, > >>>>>>> > >>>>>>> As mentioned in the email about the November 26th design team > >>>>>>> meeting, there was consensus amongst those on the call that SDP > >>>>>>> should be used for expressing encoding limits for CLUE. Rob's > >>>>>>> presentation had details as to how it could be done using the > >>>>>>> CLUE protocol, but it was decided (amongst those on the call) > >>>>>>> that we should go with the SDP approach for now and IF an issue > >>>>>>> is encountered with that approach as details are worked we could > >>>>>>> go back to the alternative proposal outlined in those charts. > >>>>>>> > >>>>>>> To move forward, we want to ensure that there is WG consensus > >>>>>>> for using SDP for the encoding limits. If anyone has any > >>>>>>> concerns about that approach, please post a note explaining why > >>>>>>> no later than > >> Dec > >>>>>>> 9th, 2013. If you weren't at the design team meeting and would > like > >>>>>>> to express your support for the approach, that's also a good idea= . > >>>>>>> > >>>>>>> Regards, > >>>>>>> Mary > >>>>>>> As WG co-chair > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> clue mailing list > >>>>>>> clue@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > > From Christian.Groves@nteczone.com Wed Dec 4 17:02:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35361AE1E2 for ; Wed, 4 Dec 2013 17:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ghhXAwQJfC for ; Wed, 4 Dec 2013 17:02:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D2E1AE1DE for ; Wed, 4 Dec 2013 17:02:11 -0800 (PST) Received: from ppp118-209-3-225.lns20.mel4.internode.on.net ([118.209.3.225]:53008 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VoNJ4-0000KU-Jj; Thu, 05 Dec 2013 12:00:42 +1100 Message-ID: <529FD08A.7010701@nteczone.com> Date: Thu, 05 Dec 2013 12:02:02 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Roni Even , "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com>, <529E62F2.7090101@nteczone.com> <760B7D45D1EFF74988DBF5C2122830C23E548DBF@szxpml507-mbs.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C23E548DBF@szxpml507-mbs.exmail.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:02:14 -0000 Hello Roni, Please see below. Regards, Christian On 5/12/2013 12:21 AM, Roni Even wrote: > Hi, > I would like to get clarfication only about the proposal, i think this will help us adopt this proposal. > > > > Finally to re-iterate what the proposal is from the draft: >> 1. The addition of a capture attribute "Meeting Role" attribute >> with values as per section 3.1 and 3.2. > Are the meeting roles in section 3.1 enumareted value or free text (for human or machine selection?). If for machine selection, is there a priority selection order (pre defined preference) or is it left to each aplication decision. > Is the behavior of the consumer different between 3.1 and 3.2? [CNG] The idea is that the values in section 3.1 would be Enumerations as these are common meeting functions. This would allow for easier human and machine selection. There would however be the option to have free text in this field (instead of an enumeration) for other not so common meeting roles that may be specific to a meeting. There wouldn't be any priority selection order as this would be up to a local policy at the Consumer. If the Advertiser wanted to assign a priority to the capture it could use the existing priority attribute in addition. > > >> 2. The addition of a capture attribute "Conference System >> Control Role" attribute with values as per section 3.3. > Are these values to be enumarted or just text. are they used by the system or just diaplayed by the application. [CNG] The intention is that these are enumerated. They would be used for capture selection and/or displayed. >> 3. The addition of a capture attribute "vCard" that allows one >> or more vCards according to [RFC6350] to be associated with a >> capture. > How do you see the linkage between a vCard and specfic person in a capture? [CNG] There would be a possibility to have multiple vCards per capture. This would the case where if multiple people were captured they could each provide vCard information. > >> 4. The addition of a capture attribute "End point vCard" that >> allows a "group", "org" or "location" kind of vCard according >> to section 6.1.4/[RFC6350] to be associated with a capture. > > Roni > > > ________________________________________ > From: clue [clue-bounces@ietf.org] on behalf of Christian Groves [Christian.Groves@nteczone.com] > Sent: Wednesday, December 04, 2013 1:02 AM > To: clue@ietf.org > Subject: Re: [clue] Roles > > Hello all, > > Does anyone have any more concerns or comments about the "roles" work? > > It would be good to get your comments as soon as possible so that I > could either address then via the list or prepare slides for next week's > design team meeting to address them. > > Regards, Christian > > On 25/11/2013 12:20 PM, Christian Groves wrote: >> Hello all, >> >> I'd like to pick up the discussion on roles from the last CLUE WG >> meeting and try and make some progress via email before the design >> team meeting. >> >> First i'd like to clarify that "role" is not intended to be a single >> attribute and it can have different meanings. My draft >> (draft-groves-clue-role-clarifications-00) seeks to clarify and >> provide a terminology to be more specific. I.e.: >> 2.1. Meeting Roles >> 2.2. Conference System Control Roles >> 2.3. Institution type >> 2.4. Person Name Title >> 2.5. Person Occupation (Job Title) >> 2.6. Organisation Name >> 2.7. Meeting Specific Roles >> >> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the >> draft. 2.1 and 2.7 have also been grouped by the draft. >> >> There has been some concern that "roles" overlap with floor control. >> From the role categories above I believe this is only relevant for >> "conference system control" roles. >> >> Secondly the intended purpose of including "roles" into CLUE is not >> for conference control or rostering but is for the selection of >> Scenes/Captures and may be used for any subsequent rendering decisions >> like the other CLUE attributes. The focus of the CLUE work has been to >> focus on selecting captures based on technical aspects (what) e.g. >> spatial properties but I think we've missed a more important aspect >> that captures will depict people or entities (who). As a consumer I'm >> likely to be more interested in who rather than what. For example if I >> have a limited system and have received an Advertisement advertising 3 >> Captures(left/centre/right) and I have only one screen so must choose >> one. One could choose the centre but this is a problem if my boss is >> sitting in the left capture. >> >> Thirdly because CLUE enhances the support of multiple streams there is >> likely to be a larger set of captures being advertised. Information >> about sources scenes/captures including different combinations may be >> sent to a consumer providing much more choice. Each of these >> scenes/captures may have different role information. Rather than try >> to implement role across several different methods and introduce >> dependencies between CLUE and other methods (e.g. conference package >> or SDP which have no Scene/capture/MCC concepts) it is most >> straightforward to send the information where it is needed i.e. in CLUE. >> >> Fourthly we have included the "description" parameter at the Scene,CSE >> and Capture level. I think people will use those as de-facto for >> "role" type information e.g. Scene Description="Company X VIC meeting >> room". Rather than have a completely unstructured usage of description >> I think that having "role" type information provided in a structured >> form (i.e. via vCard) will at least provide a consumer the ability to >> do some intelligent processing/rendering of the information. By >> allowing this "role" information to be sent in a structured way via >> CLUE I think will be an enabler for some interesting services and >> features. >> >> Finally to re-iterate what the proposal is from the draft: >> 1. The addition of a capture attribute "Meeting Role" attribute >> with values as per section 3.1 and 3.2. >> 2. The addition of a capture attribute "Conference System >> Control Role" attribute with values as per section 3.3. >> 3. The addition of a capture attribute "vCard" that allows one >> or more vCards according to [RFC6350] to be associated with a >> capture. >> 4. The addition of a capture attribute "End point vCard" that >> allows a "group", "org" or "location" kind of vCard according >> to section 6.1.4/[RFC6350] to be associated with a capture. >> >> Comments? >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Dec 4 17:17:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9501ADFBE for ; Wed, 4 Dec 2013 17:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Udh7W8Bbgf9c for ; Wed, 4 Dec 2013 17:17:18 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682D1ADFA9 for ; Wed, 4 Dec 2013 17:17:18 -0800 (PST) Received: from ppp118-209-3-225.lns20.mel4.internode.on.net ([118.209.3.225]:53209 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VoNXj-0002ev-J5; Thu, 05 Dec 2013 12:15:51 +1100 Message-ID: <529FD417.70308@nteczone.com> Date: Thu, 05 Dec 2013 12:17:11 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> <529FBE0C.5080606@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2703@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6048B2703@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:17:20 -0000 Hello Mark, Yes it seems we're on the same page. With regards to the examples I agree that we decided to keep the framework at a higher level. Perhaps we could show the encoding information in a table based structure as we do elsewhere in CLUE?, i.e. +=======================+=================================+ | EncodingGroup #1 | ENC0,ENC1 | +=======================+=================================+ +=======================+=================================+ | Encodings | Parameters| +-----------------------|---------------------------------+ | ENC0 | Media=Video | | | maxWidth=1920| | | maxHeight=1088| +-----------------------|---------------------------------+ | ENC1 | Media=Video | | | maxWidth=1200| | | maxHeight=720 | +=======================+=================================+ We could have a note at the start of the examples indicating that the information in the "encoding group" table is carried by CLUE and the information in the Encodings tables are expected to be carried outside CLUE (e.g. via SDP). I think that would make it clear. Regards, Christian On 5/12/2013 11:03 AM, Duckworth, Mark wrote: > Hi Christian, > > I think we have same understanding about the concept, but are having trouble with terminology. In any case, I think we are both agreeing on using SDP to express encoding limits, but are now discussing possible impact to the framework document. > > Comments inline. > > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Wednesday, December 04, 2013 6:43 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? >> >> Hello Mark, >> >> Please see my response below. >> >> Regards, Christian >> >> On 5/12/2013 4:15 AM, Duckworth, Mark wrote: >>> Hi Christian, >>> >>> Maybe there is confusion about "encoding limits" vs. "encoding >> parameters". I think we have been talking about "limits" and "parameters" >> as being the same thing. Here is my understanding. A CLUE encoding has >> "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and draft- >> kyzivat-clue-signaling-05 section 4.2). For the sender (encoder side), these >> are expressed in SDP (a=sendonly), and referenced in a CLUE advertisement. >> Similarly, for the receiver (decoder side) the limits are expressed in SDP >> (a=recvonly) and referenced in a CLUE configure message. >> [CNG] This is where I'm confused. You say CLUE has "encoding limits" but the >> decision is that SDP has the encoding limits. I would say CLUE references an >> encoding defined by SDP. It is up to SDP to define that encoding in whatever >> way. I.e. it may have a specific encoding and/or may also have attributes that >> define limits. CLUE groups the encodings. > [Duckworth, Mark] Sorry, I wasn't clear. I meant the CLUE framework includes encoding limits. A CLUE encoding has encoding limits. These encoding limits are expressed in SDP and referenced by CLUE protocol messages. Does that make more sense? > >>> Framework section 8.1 mentions the possibility of the codec actually using >> lower values for some of these parameters, and gives example of how >> certain parameters for certain codecs can be considered limits with possibility >> of using lower values. It seems to me that in general this isn't CLUE specific. >> This is just how these parameters are meant to be used in SDP offer/answer >> (and maybe also in H.323 protocol?). CLUE isn't trying to change this, it is just >> adding the ability to reference these existing codec parameters in CLUE >> messages. >> [CNG] OK this is another thing I didn't understand from the proposal. >> Again I thought we just reference the SDP encoding, not the individual SDP >> parameters in the CLUE messages? > [Duckworth, Mark] I didn't mean there are references to individual parameters. I think your first idea is correct, a CLUE message associates a CLUE encoding with an SDP m-line and other information in SDP included with the m-line, and this includes the encoding parameters. > >>> I disagree with you about the consistency of the framework examples. The >> "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters >> you mentioned are all still part of the framework. Whether they are >> expressed directly in CLUE messages or references to SDP is not relevant to >> these examples. If we eventually add more examples (in the signaling >> document?) for CLUE protocol and/or using the data model, then these >> lower level details should appear in those examples. >> [CNG] I think the issue is that the start of the text of section 8.1 and the >> examples was when the encoding parameters were present in CLUE itself. If >> we now say SDP contains the encoding information its not up to CLUE to say >> how these SDP parameters are interpreted. i.e. section >> 8.1 says "The parameters of an Individual Encoding represent the maximum >> values for certain aspects of the encoding." This is not the case for all SDP >> parameters/attributes. What they represent is up to the semantics of the >> SDP parameter itself. > [Duckworth, Mark] Okay, I understand that. Further down in section 8.1 I think it explains it better, but maybe we can clean it up further. > >> Also when I look at the example it certainly implies that the parameters are >> part of CLUE i.e. associated with the encoding rather than CLUE referencing >> an encoding defined elsewhere. >> E.g. CLUE has: >> encodeGroupID=EG0, maxGroupBandwidth=6000000 >> encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, >> maxPps=124416000, maxBandwidth=4000000 >> encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, >> maxPps=27648000, maxBandwidth=4000000 >> encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, >> maxPps=15552000, maxBandwidth=4000000 >> >> Which to me at least implies they are all part of the same syntax definition. >> >> Whereas to show that the parameters are defined outside CLUE I would >> expect something like: >> Encoding Groups: >> encodeGroupID=EG0, maxGroupBandwidth=6000000 >> encodeID=ENC0 >> encodeID=ENC1 >> encodeID=ENC2 >> >> Encodings: >> m=video >> label=ENC0 >> a=maxWidth:1920 >> a=maxHeight:1088 >> ... >> m=video >> label=ENC1 >> a=maxWidth:1280 >> a=maxHeight:720 >> ... >> etc. >> >> The above SDP isn't correct but I'm just try to illustrate that it would be good >> to show the define of the parameters separate from the definition of the >> encoding groups. It could be abstracted not to have SDP. > [Duckworth, Mark] I understand. I guess it depends on how much "syntax detail" you want to show in the examples, even though it isn't really proper CLUE data model or protocol or SDP syntax at all. My view is the example is okay as is, without adding more syntax detail. I thought the working group agreed in general these framework examples should be fairly high level and not get bogged down in syntax. > [Duckworth, Mark] Does anybody else have input about this? > >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>> Sent: Tuesday, December 03, 2013 5:50 PM >>>> To: Duckworth, Mark; clue@ietf.org >>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? >>>> >>>> Hello Mark, >>>> >>>> I guess what I found confusing is that the decision was with regards >>>> to "Encoding Limits" (i.e. maximums) not encoding parameters which I >>>> agree we've previously thought as being in SDP. The examples in the >>>> framework also shows >>>> maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth >>>> against individual encodes. So the framework isn't consistent on this. >>>> >>>> Regards, Christian >>>> >>>> On 4/12/2013 1:17 AM, Duckworth, Mark wrote: >>>>> Hello Christian, >>>>> >>>>> I agree with Rob, and even further, I think the Framework document >>>>> is >>>> already consistent with this approach, because it has been our >>>> working understanding for quite a while. >>>>> This text from section 8.1 sums it up nicely: >>>>> "Individual Encoding parameters are represented in SDP [RFC4566], >>>>> not in CLUE messages. For example, for a video encoding using >>>>> H.26x compression technologies, this can include parameters such >>>>> as: >>>>> . Maximum bandwidth; >>>>> . Maximum picture size in pixels; >>>>> . Maximum number of pixels to be processed per second; >>>>> The bandwidth parameter is the only one that specifically relates >>>>> to a CLUE Advertisement, as it can be further constrained by the >>>>> maximum group bandwidth in an Encoding Group." >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>> Groves >>>>>> Sent: Monday, December 02, 2013 5:55 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE >> signaling? >>>>>> Hello Rob, >>>>>> >>>>>> So we'll keep the encoding group concept but there will be no CLUE >>>>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps >>>> etc)? >>>>>> Regards, Christian >>>>>> >>>>>> On 3/12/2013 3:29 AM, Robert Hansen wrote: >>>>>>> Hi Christian, >>>>>>> >>>>>>> I don't think this affects Encoding Groups - that concept will >>>>>>> still be in the framework and will need to be expressed in CLUE >>>>>>> ADVERTISMENT messages, as that's something that isn't well >>>>>>> expressible in SDP. The encoding limits referred to are the >>>>>>> per-encoding >>>> limits. >>>>>>> This reflects what we had been taking as our working understanding >>>>>>> so far in things like the signalling document, so shouldn't >>>>>>> involve a radical rethink. >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> On 02/12/2013 01:04, Christian Groves wrote: >>>>>>>> Hello Mary, all, >>>>>>>> >>>>>>>> In general I'm OK with expressing coding limits in SDP. However >>>>>>>> I'm trying to understand what the impact is to the CLUE framework >>>>>>>> as a result of that decision. Does that then mean the entire >>>>>>>> encoding group concept (i.e. section 8 and 9 (and relevant >>>>>>>> examples)) are removed from the framework and that a Capture >>>>>>>> Encoding is now effectively a CaptureID and reference to an SDP m- >> line? or? >>>>>>>> Regards, Christian >>>>>>>> >>>>>>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>>>>>>>> HI all, >>>>>>>>> >>>>>>>>> As mentioned in the email about the November 26th design team >>>>>>>>> meeting, there was consensus amongst those on the call that SDP >>>>>>>>> should be used for expressing encoding limits for CLUE. Rob's >>>>>>>>> presentation had details as to how it could be done using the >>>>>>>>> CLUE protocol, but it was decided (amongst those on the call) >>>>>>>>> that we should go with the SDP approach for now and IF an issue >>>>>>>>> is encountered with that approach as details are worked we could >>>>>>>>> go back to the alternative proposal outlined in those charts. >>>>>>>>> >>>>>>>>> To move forward, we want to ensure that there is WG consensus >>>>>>>>> for using SDP for the encoding limits. If anyone has any >>>>>>>>> concerns about that approach, please post a note explaining why >>>>>>>>> no later than >>>> Dec >>>>>>>>> 9th, 2013. If you weren't at the design team meeting and would >> like >>>>>>>>> to express your support for the approach, that's also a good idea. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Mary >>>>>>>>> As WG co-chair >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Dec 4 17:32:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6EB1AE2C4 for ; Wed, 4 Dec 2013 17:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJkOc3cF8_Vn for ; Wed, 4 Dec 2013 17:32:11 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BC51D1ADFD1 for ; Wed, 4 Dec 2013 17:32:10 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so9160920wid.17 for ; Wed, 04 Dec 2013 17:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=24OOW0qWyw90AoJgSr6iHmfPUZNPnvrZ2RJf3yYs5bM=; b=h4wdbOh8k6Vs7NRjBKNdnMELlUBxrIfVZpRcVC7gkhf4Jeoxo1EsuzuQT17h6qr1r+ L7iNPlAwNP4AqF/exbuvXlEQSaxvBa2SSO336XkHvZ+7AdksBnvH8/WnZYafxSgf1l1z xtEZ6IyFc8urs4hCnXH4FiIoSZvnf10J84VFhly8e5EOlUTMFp+uIebWRSpGKDw4+rjI rQIzVNsKFKLlSZ9Icq8JBknNWSZnv7YjyolOepjld/v3rBINK+d27T4EDFzig3aLDOCV niOAmPQ61F4ZKXik0HLqkDm+gP8F2Mzl4LJKLSn1ud4C7tuPh2CAu4DDkqzP1tqcDyaN Zveg== MIME-Version: 1.0 X-Received: by 10.180.93.8 with SMTP id cq8mr9854505wib.38.1386207127128; Wed, 04 Dec 2013 17:32:07 -0800 (PST) Received: by 10.216.172.9 with HTTP; Wed, 4 Dec 2013 17:32:07 -0800 (PST) In-Reply-To: <529FD417.70308@nteczone.com> References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> <529FBE0C.5080606@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2703@CRPMBOXPRD07.polycom.com> <529FD417.70308@nteczone.com> Date: Wed, 4 Dec 2013 19:32:07 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=f46d043892b165cff804ecbf7f68 Cc: "clue@ietf.org" Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 01:32:15 -0000 --f46d043892b165cff804ecbf7f68 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 7:17 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Mark, > > Yes it seems we're on the same page. With regards to the examples I agree > that we decided to keep the framework at a higher level. Perhaps we could > show the encoding information in a table based structure as we do elsewhere > in CLUE?, i.e. > > +=======================+=================================+ > | EncodingGroup #1 | ENC0,ENC1 | > +=======================+=================================+ > > +=======================+=================================+ > | Encodings | Parameters| > +-----------------------|---------------------------------+ > | ENC0 | Media=Video | > | | maxWidth=1920| > | | maxHeight=1088| > +-----------------------|---------------------------------+ > | ENC1 | Media=Video | > | | maxWidth=1200| > | | maxHeight=720 | > +=======================+=================================+ > > We could have a note at the start of the examples indicating that the > information in the "encoding group" table is carried by CLUE and the > information in the Encodings tables are expected to be carried outside CLUE > (e.g. via SDP). I think that would make it clear. > [MB] As an individual I do not believe we want this note in the framework document. This level of detail should be reflected in the signaling solution document. [/MB] > > Regards, Christian > > > On 5/12/2013 11:03 AM, Duckworth, Mark wrote: > >> Hi Christian, >> >> I think we have same understanding about the concept, but are having >> trouble with terminology. In any case, I think we are both agreeing on >> using SDP to express encoding limits, but are now discussing possible >> impact to the framework document. >> >> Comments inline. >> >> Mark >> >> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Wednesday, December 04, 2013 6:43 PM >>> To: Duckworth, Mark; clue@ietf.org >>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE >>> signaling? >>> >>> Hello Mark, >>> >>> Please see my response below. >>> >>> Regards, Christian >>> >>> On 5/12/2013 4:15 AM, Duckworth, Mark wrote: >>> >>>> Hi Christian, >>>> >>>> Maybe there is confusion about "encoding limits" vs. "encoding >>>> >>> parameters". I think we have been talking about "limits" and >>> "parameters" >>> as being the same thing. Here is my understanding. A CLUE encoding has >>> "encoding limits" (see draft-ietf-clue-framework-12 section 8.1 and >>> draft- >>> kyzivat-clue-signaling-05 section 4.2). For the sender (encoder side), >>> these >>> are expressed in SDP (a=sendonly), and referenced in a CLUE >>> advertisement. >>> Similarly, for the receiver (decoder side) the limits are expressed in >>> SDP >>> (a=recvonly) and referenced in a CLUE configure message. >>> [CNG] This is where I'm confused. You say CLUE has "encoding limits" but >>> the >>> decision is that SDP has the encoding limits. I would say CLUE >>> references an >>> encoding defined by SDP. It is up to SDP to define that encoding in >>> whatever >>> way. I.e. it may have a specific encoding and/or may also have >>> attributes that >>> define limits. CLUE groups the encodings. >>> >> [Duckworth, Mark] Sorry, I wasn't clear. I meant the CLUE framework >> includes encoding limits. A CLUE encoding has encoding limits. These >> encoding limits are expressed in SDP and referenced by CLUE protocol >> messages. Does that make more sense? >> >> Framework section 8.1 mentions the possibility of the codec actually >>>> using >>>> >>> lower values for some of these parameters, and gives example of how >>> certain parameters for certain codecs can be considered limits with >>> possibility >>> of using lower values. It seems to me that in general this isn't CLUE >>> specific. >>> This is just how these parameters are meant to be used in SDP >>> offer/answer >>> (and maybe also in H.323 protocol?). CLUE isn't trying to change this, >>> it is just >>> adding the ability to reference these existing codec parameters in CLUE >>> messages. >>> [CNG] OK this is another thing I didn't understand from the proposal. >>> Again I thought we just reference the SDP encoding, not the individual >>> SDP >>> parameters in the CLUE messages? >>> >> [Duckworth, Mark] I didn't mean there are references to individual >> parameters. I think your first idea is correct, a CLUE message associates >> a CLUE encoding with an SDP m-line and other information in SDP included >> with the m-line, and this includes the encoding parameters. >> >> I disagree with you about the consistency of the framework examples. The >>>> >>> "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" parameters >>> you mentioned are all still part of the framework. Whether they are >>> expressed directly in CLUE messages or references to SDP is not relevant >>> to >>> these examples. If we eventually add more examples (in the signaling >>> document?) for CLUE protocol and/or using the data model, then these >>> lower level details should appear in those examples. >>> [CNG] I think the issue is that the start of the text of section 8.1 and >>> the >>> examples was when the encoding parameters were present in CLUE itself. If >>> we now say SDP contains the encoding information its not up to CLUE to >>> say >>> how these SDP parameters are interpreted. i.e. section >>> 8.1 says "The parameters of an Individual Encoding represent the maximum >>> values for certain aspects of the encoding." This is not the case for >>> all SDP >>> parameters/attributes. What they represent is up to the semantics of the >>> SDP parameter itself. >>> >> [Duckworth, Mark] Okay, I understand that. Further down in section 8.1 I >> think it explains it better, but maybe we can clean it up further. >> >> Also when I look at the example it certainly implies that the parameters >>> are >>> part of CLUE i.e. associated with the encoding rather than CLUE >>> referencing >>> an encoding defined elsewhere. >>> E.g. CLUE has: >>> encodeGroupID=EG0, maxGroupBandwidth=6000000 >>> encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, >>> maxPps=124416000, maxBandwidth=4000000 >>> encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, >>> maxPps=27648000, maxBandwidth=4000000 >>> encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, >>> maxPps=15552000, maxBandwidth=4000000 >>> >>> Which to me at least implies they are all part of the same syntax >>> definition. >>> >>> Whereas to show that the parameters are defined outside CLUE I would >>> expect something like: >>> Encoding Groups: >>> encodeGroupID=EG0, maxGroupBandwidth=6000000 >>> encodeID=ENC0 >>> encodeID=ENC1 >>> encodeID=ENC2 >>> >>> Encodings: >>> m=video >>> label=ENC0 >>> a=maxWidth:1920 >>> a=maxHeight:1088 >>> ... >>> m=video >>> label=ENC1 >>> a=maxWidth:1280 >>> a=maxHeight:720 >>> ... >>> etc. >>> >>> The above SDP isn't correct but I'm just try to illustrate that it would >>> be good >>> to show the define of the parameters separate from the definition of the >>> encoding groups. It could be abstracted not to have SDP. >>> >> [Duckworth, Mark] I understand. I guess it depends on how much "syntax >> detail" you want to show in the examples, even though it isn't really >> proper CLUE data model or protocol or SDP syntax at all. My view is the >> example is okay as is, without adding more syntax detail. I thought the >> working group agreed in general these framework examples should be fairly >> high level and not get bogged down in syntax. >> [Duckworth, Mark] Does anybody else have input about this? >> >> Regards, >>>> Mark >>>> >>>> -----Original Message----- >>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>>> Sent: Tuesday, December 03, 2013 5:50 PM >>>>> To: Duckworth, Mark; clue@ietf.org >>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE >>>>> signaling? >>>>> >>>>> Hello Mark, >>>>> >>>>> I guess what I found confusing is that the decision was with regards >>>>> to "Encoding Limits" (i.e. maximums) not encoding parameters which I >>>>> agree we've previously thought as being in SDP. The examples in the >>>>> framework also shows >>>>> maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth >>>>> against individual encodes. So the framework isn't consistent on this. >>>>> >>>>> Regards, Christian >>>>> >>>>> On 4/12/2013 1:17 AM, Duckworth, Mark wrote: >>>>> >>>>>> Hello Christian, >>>>>> >>>>>> I agree with Rob, and even further, I think the Framework document >>>>>> is >>>>>> >>>>> already consistent with this approach, because it has been our >>>>> working understanding for quite a while. >>>>> >>>>>> This text from section 8.1 sums it up nicely: >>>>>> "Individual Encoding parameters are represented in SDP >>>>>> [RFC4566], >>>>>> not in CLUE messages. For example, for a video encoding using >>>>>> H.26x compression technologies, this can include parameters >>>>>> such >>>>>> as: >>>>>> . Maximum bandwidth; >>>>>> . Maximum picture size in pixels; >>>>>> . Maximum number of pixels to be processed per second; >>>>>> The bandwidth parameter is the only one that specifically >>>>>> relates >>>>>> to a CLUE Advertisement, as it can be further constrained by >>>>>> the >>>>>> maximum group bandwidth in an Encoding Group." >>>>>> >>>>>> Mark >>>>>> >>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>> Groves >>>>>>> Sent: Monday, December 02, 2013 5:55 PM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE >>>>>>> >>>>>> signaling? >>> >>>> Hello Rob, >>>>>>> >>>>>>> So we'll keep the encoding group concept but there will be no CLUE >>>>>>> encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps >>>>>>> >>>>>> etc)? >>>>> >>>>>> Regards, Christian >>>>>>> >>>>>>> On 3/12/2013 3:29 AM, Robert Hansen wrote: >>>>>>> >>>>>>>> Hi Christian, >>>>>>>> >>>>>>>> I don't think this affects Encoding Groups - that concept will >>>>>>>> still be in the framework and will need to be expressed in CLUE >>>>>>>> ADVERTISMENT messages, as that's something that isn't well >>>>>>>> expressible in SDP. The encoding limits referred to are the >>>>>>>> per-encoding >>>>>>>> >>>>>>> limits. >>>>> >>>>>> This reflects what we had been taking as our working understanding >>>>>>>> so far in things like the signalling document, so shouldn't >>>>>>>> involve a radical rethink. >>>>>>>> >>>>>>>> Rob >>>>>>>> >>>>>>>> On 02/12/2013 01:04, Christian Groves wrote: >>>>>>>> >>>>>>>>> Hello Mary, all, >>>>>>>>> >>>>>>>>> In general I'm OK with expressing coding limits in SDP. However >>>>>>>>> I'm trying to understand what the impact is to the CLUE framework >>>>>>>>> as a result of that decision. Does that then mean the entire >>>>>>>>> encoding group concept (i.e. section 8 and 9 (and relevant >>>>>>>>> examples)) are removed from the framework and that a Capture >>>>>>>>> Encoding is now effectively a CaptureID and reference to an SDP m- >>>>>>>>> >>>>>>>> line? or? >>> >>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 30/11/2013 8:24 AM, Mary Barnes wrote: >>>>>>>>> >>>>>>>>>> HI all, >>>>>>>>>> >>>>>>>>>> As mentioned in the email about the November 26th design team >>>>>>>>>> meeting, there was consensus amongst those on the call that SDP >>>>>>>>>> should be used for expressing encoding limits for CLUE. Rob's >>>>>>>>>> presentation had details as to how it could be done using the >>>>>>>>>> CLUE protocol, but it was decided (amongst those on the call) >>>>>>>>>> that we should go with the SDP approach for now and IF an issue >>>>>>>>>> is encountered with that approach as details are worked we could >>>>>>>>>> go back to the alternative proposal outlined in those charts. >>>>>>>>>> >>>>>>>>>> To move forward, we want to ensure that there is WG consensus >>>>>>>>>> for using SDP for the encoding limits. If anyone has any >>>>>>>>>> concerns about that approach, please post a note explaining why >>>>>>>>>> no later than >>>>>>>>>> >>>>>>>>> Dec >>>>> >>>>>> 9th, 2013. If you weren't at the design team meeting and would >>>>>>>>>> >>>>>>>>> like >>> >>>> to express your support for the approach, that's also a good idea. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Mary >>>>>>>>>> As WG co-chair >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> clue mailing list >>>>>>>>>> clue@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> clue mailing list >>>>>>>>> clue@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> clue mailing list >>>>>>>> clue@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> clue mailing list >>>>>>> clue@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>>>> >>>>>> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d043892b165cff804ecbf7f68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 4, 2013 at 7:17 PM,= Christian Groves <Christian.Groves@nteczone.com> wrote:
Hello Mark,

Yes it seems we're on the same page. With regards to the examples I agr= ee that we decided to keep the framework at a higher level. Perhaps we coul= d show the encoding information in a table based structure as we do elsewhe= re in CLUE?, i.e.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| EncodingGroup #1 | ENC0,ENC1 |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
| Encodings | Parameters|
+-----------------------|---------------------------------+
| ENC0 | Media=3DVideo |
| | maxWidth=3D1920|
| | maxHeight=3D1088|
+-----------------------|---------------------------------+
| ENC1 | Media=3DVideo |
| | maxWidth=3D1200|
| | maxHeight=3D720 |
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

We could have a note at the start of the examples indicating that the infor= mation in the "encoding group" table is carried by CLUE and the i= nformation in the Encodings tables are expected to be carried outside CLUE = (e.g. via SDP). I think that would make it clear.
[MB] As an individual I do not believe we want this= note in the framework document. This level of detail should be reflected i= n the signaling solution document. =A0
[/MB]

Regards, Christian


On 5/12/2013 11:03 AM, Duckworth, Mark wrote:
Hi Christian,

I think we have same understanding about the concept, but are having troubl= e with terminology. =A0In any case, I think we are both agreeing on using S= DP to express encoding limits, but are now discussing possible impact to th= e framework document.

Comments inline.

Mark

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@nteczone.com]
Sent: Wednesday, December 04, 2013 6:43 PM
To: Duckworth, Mark; clu= e@ietf.org
Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling= ?

Hello Mark,

Please see my response below.

Regards, Christian

On 5/12/2013 4:15 AM, Duckworth, Mark wrote:
Hi Christian,

Maybe there is confusion about "encoding limits" vs. "encodi= ng
parameters". =A0I think we have been talking about "limits" = and "parameters"
as being the same thing. =A0Here is my understanding. =A0A CLUE encoding ha= s
"encoding limits" (see draft-ietf-clue-framework-12 section 8.1 a= nd draft-
kyzivat-clue-signaling-05 section 4.2). =A0For the sender (encoder side), t= hese
are expressed in SDP (a=3Dsendonly), and referenced in a CLUE advertisement= .
Similarly, for the receiver (decoder side) the limits are expressed in SDP<= br> (a=3Drecvonly) and referenced in a CLUE configure message.
[CNG] This is where I'm confused. You say CLUE has "encoding limit= s" but the
decision is that SDP has the encoding limits. I would say CLUE references a= n
encoding defined by SDP. It is up to SDP to define that encoding in whateve= r
way. I.e. it may have a specific encoding and/or may also have attributes t= hat
define limits. CLUE groups the encodings.
[Duckworth, Mark] Sorry, I wasn't clear. =A0I meant the CLUE framework = includes =A0encoding limits. =A0A CLUE encoding has encoding limits. =A0The= se encoding limits are expressed in SDP and referenced by CLUE protocol mes= sages. =A0Does that make more sense?

Framework section 8.1 mentions the possibility of the codec actually using<= br>
lower values for some of these parameters, and gives example of how
certain parameters for certain codecs can be considered limits with possibi= lity
of using lower values. =A0It seems to me that in general this isn't CLU= E specific.
This is just how these parameters are meant to be used in SDP offer/answer<= br> (and maybe also in H.323 protocol?). =A0CLUE isn't trying to change thi= s, it is just
adding the ability to reference these existing codec parameters in CLUE
messages.
[CNG] OK this is another thing I didn't understand from the proposal. Again I thought we just reference the SDP encoding, not the individual SDP<= br> parameters in the CLUE messages?
[Duckworth, Mark] I didn't mean there are references to individual para= meters. =A0I think your first idea is correct, a CLUE message associates a = CLUE encoding with an SDP m-line and other information in SDP included with= the m-line, and this includes the encoding parameters.

I disagree with you about the consistency of the framework examples. =A0The=
"maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth&quo= t; parameters
you mentioned are all still part of the framework. =A0Whether they are
expressed directly in CLUE messages or references to SDP is not relevant to=
these examples. =A0If we eventually add more examples (in the signaling
document?) for CLUE protocol and/or using the data model, then these
lower level details should appear in those examples.
[CNG] I think the issue is that the start of the text of section 8.1 and th= e
examples was when the encoding parameters were present in CLUE itself. If we now say SDP contains the encoding information its not up to CLUE to say<= br> how these SDP parameters are interpreted. i.e. section
8.1 says "The parameters of an Individual Encoding represent the maxim= um
values for certain aspects of the encoding." This is not the case for = all SDP
parameters/attributes. What they represent is up to the semantics of the SDP parameter itself.
[Duckworth, Mark] Okay, I understand that. =A0Further down in section 8.1 I= think it explains it better, but maybe we can clean it up further.

Also when I look at the example it certainly implies that the parameters ar= e
part of CLUE i.e. associated with the encoding rather than CLUE referencing=
an encoding defined elsewhere.
E.g. CLUE has:
=A0 =A0 encodeGroupID=3DEG0, maxGroupBandwidth=3D6000000
=A0 =A0 =A0 =A0 =A0encodeID=3DENC0, maxWidth=3D1920, maxHeight=3D1088, maxF= rameRate=3D60,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maxPps=3D124416000, maxBand= width=3D4000000
=A0 =A0 =A0 =A0 =A0encodeID=3DENC1, maxWidth=3D1280, maxHeight=3D720, maxFr= ameRate=3D30,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maxPps=3D27648000, maxBandw= idth=3D4000000
=A0 =A0 =A0 =A0 =A0encodeID=3DENC2, maxWidth=3D960, maxHeight=3D544, maxFra= meRate=3D30,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 maxPps=3D15552000, maxBandw= idth=3D4000000

Which to me at least implies they are all part of the same syntax definitio= n.

Whereas to show that the parameters are defined outside CLUE I would
expect something like:
Encoding Groups:
encodeGroupID=3DEG0, maxGroupBandwidth=3D6000000
=A0 =A0 =A0 =A0 =A0encodeID=3DENC0
=A0 =A0 =A0 =A0 =A0encodeID=3DENC1
=A0 =A0 =A0 =A0 =A0encodeID=3DENC2

Encodings:
=A0 =A0 =A0 =A0 =A0m=3Dvideo
=A0 =A0 =A0 =A0 =A0label=3DENC0
=A0 =A0 =A0 =A0 =A0a=3DmaxWidth:1920
=A0 =A0 =A0 =A0 =A0a=3DmaxHeight:1088
=A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0m=3Dvideo
=A0 =A0 =A0 =A0 =A0label=3DENC1
=A0 =A0 =A0 =A0 =A0a=3DmaxWidth:1280
=A0 =A0 =A0 =A0 =A0a=3DmaxHeight:720
=A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0etc.

The above SDP isn't correct but I'm just try to illustrate that it = would be good
to show the define of the parameters separate from the definition of the encoding groups. It could be abstracted not to have SDP.
[Duckworth, Mark] I understand. =A0I guess it depends on how much "syn= tax detail" you want to show in the examples, even though it isn't= really proper CLUE data model or protocol or SDP syntax at all. =A0My view= is the example is okay as is, without adding more syntax detail. =A0I thou= ght the working group agreed in general these framework examples should be = fairly high level and not get bogged down in syntax.
[Duckworth, Mark] Does anybody else have input about this?

Regards,
Mark

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@nteczone.com]
Sent: Tuesday, December 03, 2013 5:50 PM
To: Duckworth, Mark; clu= e@ietf.org
Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling= ?

Hello Mark,

I guess what I found confusing is that the decision was with regards
to "Encoding Limits" (i.e. maximums) not encoding parameters whic= h I
agree we've previously thought as being in SDP. The examples in the
framework also shows
maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth
against individual encodes. So the framework isn't consistent on this.<= br>
Regards, Christian

On 4/12/2013 1:17 AM, Duckworth, Mark wrote:
Hello Christian,

I agree with Rob, and even further, I think the Framework document
is
already consistent with this approach, because it has been our
working understanding for quite a while.
This text from section 8.1 sums it up nicely:
=A0 =A0 =A0 =A0"Individual Encoding parameters are represented in SDP = [RFC4566],
=A0 =A0 =A0 =A0not in CLUE messages. For example, for a video encoding usin= g
=A0 =A0 =A0 =A0H.26x compression technologies, this can include parameters = such
=A0 =A0 =A0 =A0as:
=A0 =A0 =A0 =A0. Maximum bandwidth;
=A0 =A0 =A0 =A0. Maximum picture size in pixels;
=A0 =A0 =A0 =A0. Maximum number of pixels to be processed per second;
=A0 =A0 =A0 =A0The bandwidth parameter is the only one that specifically re= lates
=A0 =A0 =A0 =A0to a CLUE Advertisement, as it can be further constrained by= the
=A0 =A0 =A0 =A0maximum group bandwidth in an Encoding Group."

Mark

-----Original Message-----
From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian
Groves
Sent: Monday, December 02, 2013 5:55 PM
To: clue@ietf.org Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE
signaling?
Hello Rob,

So we'll keep the encoding group concept but there will be no CLUE
encoding parameters (i.e. no maxGroupBandwidth, maxWidth, maxPps
etc)?
Regards, Christian

On 3/12/2013 3:29 AM, Robert Hansen wrote:
Hi Christian,

I don't think this affects Encoding Groups - that concept will
still be in the framework and will need to be expressed in CLUE
ADVERTISMENT messages, as that's something that isn't well
expressible in SDP. The encoding limits referred to are the
per-encoding
limits.
This reflects what we had been taking as our working understanding
so far in things like the signalling document, so shouldn't
involve a radical rethink.

Rob

On 02/12/2013 01:04, Christian Groves wrote:
Hello Mary, all,

In general I'm OK with expressing coding limits in SDP. However
I'm trying to understand what the impact is to the CLUE framework
as a result of that decision. Does that then mean the entire
encoding group concept (i.e. section 8 and 9 (and relevant
examples)) are removed from the framework and that a Capture
Encoding is now effectively a CaptureID and reference to an SDP m-
line? or?
Regards, Christian

On 30/11/2013 8:24 AM, Mary Barnes wrote:
HI all,

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

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

Regards,
Mary
As WG co-chair


_______________________________________________
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
_______________________________________________
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


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

--f46d043892b165cff804ecbf7f68-- From Christian.Groves@nteczone.com Wed Dec 4 18:12:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF51ADF7E for ; Wed, 4 Dec 2013 18:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_55=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2LA2V2tOI1a for ; Wed, 4 Dec 2013 18:12:11 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835AE1ADFFC for ; Wed, 4 Dec 2013 18:12:10 -0800 (PST) Received: from ppp118-209-3-225.lns20.mel4.internode.on.net ([118.209.3.225]:53988 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VoOOo-0003IE-Gx; Thu, 05 Dec 2013 13:10:42 +1100 Message-ID: <529FE0F2.1080405@nteczone.com> Date: Thu, 05 Dec 2013 13:12:02 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes References: <529BDC8E.4010402@nteczone.com> <529CB55B.80303@cisco.com> <529D0FAE.1080303@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6046A2B8A@CRPMBOXPRD07.polycom.com> <529E6034.8010009@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2428@CRPMBOXPRD07.polycom.com> <529FBE0C.5080606@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B2703@CRPMBOXPRD07.polycom.com> <529FD417.70308@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Cc: "clue@ietf.org" Subject: Re: [clue] Consensus call: Encoding Limits - SDP or CLUE signaling? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 02:12:13 -0000 Hello Mary, But doesn't the note reflect the decision we're making to define encoding information in SDP i.e. outside of CLUE? I would think its important for the framework to provide this delineation, its also in-line with what is already in the framework in section 8.1 " Individual Encoding parameters are represented in SDP [RFC4566], not in CLUE messages." Are you suggesting that we remove that line? Regards, Christian On 5/12/2013 12:32 PM, Mary Barnes wrote: > On Wed, Dec 4, 2013 at 7:17 PM, Christian Groves > > > wrote: > > Hello Mark, > > Yes it seems we're on the same page. With regards to the examples > I agree that we decided to keep the framework at a higher level. > Perhaps we could show the encoding information in a table based > structure as we do elsewhere in CLUE?, i.e. > > +=======================+=================================+ > | EncodingGroup #1 | ENC0,ENC1 | > +=======================+=================================+ > > +=======================+=================================+ > | Encodings | Parameters| > +-----------------------|---------------------------------+ > | ENC0 | Media=Video | > | | maxWidth=1920| > | | maxHeight=1088| > +-----------------------|---------------------------------+ > | ENC1 | Media=Video | > | | maxWidth=1200| > | | maxHeight=720 | > +=======================+=================================+ > > We could have a note at the start of the examples indicating that > the information in the "encoding group" table is carried by CLUE > and the information in the Encodings tables are expected to be > carried outside CLUE (e.g. via SDP). I think that would make it clear. > > [MB] As an individual I do not believe we want this note in the > framework document. This level of detail should be reflected in the > signaling solution document. > [/MB] > > > Regards, Christian > > > On 5/12/2013 11:03 AM, Duckworth, Mark wrote: > > Hi Christian, > > I think we have same understanding about the concept, but are > having trouble with terminology. In any case, I think we are > both agreeing on using SDP to express encoding limits, but are > now discussing possible impact to the framework document. > > Comments inline. > > Mark > > -----Original Message----- > From: Christian Groves > [mailto:Christian.Groves@nteczone.com > ] > Sent: Wednesday, December 04, 2013 6:43 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] Consensus call: Encoding Limits - SDP > or CLUE signaling? > > Hello Mark, > > Please see my response below. > > Regards, Christian > > On 5/12/2013 4:15 AM, Duckworth, Mark wrote: > > Hi Christian, > > Maybe there is confusion about "encoding limits" vs. > "encoding > > parameters". I think we have been talking about "limits" > and "parameters" > as being the same thing. Here is my understanding. A CLUE > encoding has > "encoding limits" (see draft-ietf-clue-framework-12 > section 8.1 and draft- > kyzivat-clue-signaling-05 section 4.2). For the sender > (encoder side), these > are expressed in SDP (a=sendonly), and referenced in a > CLUE advertisement. > Similarly, for the receiver (decoder side) the limits are > expressed in SDP > (a=recvonly) and referenced in a CLUE configure message. > [CNG] This is where I'm confused. You say CLUE has > "encoding limits" but the > decision is that SDP has the encoding limits. I would say > CLUE references an > encoding defined by SDP. It is up to SDP to define that > encoding in whatever > way. I.e. it may have a specific encoding and/or may also > have attributes that > define limits. CLUE groups the encodings. > > [Duckworth, Mark] Sorry, I wasn't clear. I meant the CLUE > framework includes encoding limits. A CLUE encoding has > encoding limits. These encoding limits are expressed in SDP > and referenced by CLUE protocol messages. Does that make more > sense? > > Framework section 8.1 mentions the possibility of the > codec actually using > > lower values for some of these parameters, and gives > example of how > certain parameters for certain codecs can be considered > limits with possibility > of using lower values. It seems to me that in general this > isn't CLUE specific. > This is just how these parameters are meant to be used in > SDP offer/answer > (and maybe also in H.323 protocol?). CLUE isn't trying to > change this, it is just > adding the ability to reference these existing codec > parameters in CLUE > messages. > [CNG] OK this is another thing I didn't understand from > the proposal. > Again I thought we just reference the SDP encoding, not > the individual SDP > parameters in the CLUE messages? > > [Duckworth, Mark] I didn't mean there are references to > individual parameters. I think your first idea is correct, a > CLUE message associates a CLUE encoding with an SDP m-line and > other information in SDP included with the m-line, and this > includes the encoding parameters. > > I disagree with you about the consistency of the > framework examples. The > > "maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth" > parameters > you mentioned are all still part of the framework. Whether > they are > expressed directly in CLUE messages or references to SDP > is not relevant to > these examples. If we eventually add more examples (in the > signaling > document?) for CLUE protocol and/or using the data model, > then these > lower level details should appear in those examples. > [CNG] I think the issue is that the start of the text of > section 8.1 and the > examples was when the encoding parameters were present in > CLUE itself. If > we now say SDP contains the encoding information its not > up to CLUE to say > how these SDP parameters are interpreted. i.e. section > 8.1 says "The parameters of an Individual Encoding > represent the maximum > values for certain aspects of the encoding." This is not > the case for all SDP > parameters/attributes. What they represent is up to the > semantics of the > SDP parameter itself. > > [Duckworth, Mark] Okay, I understand that. Further down in > section 8.1 I think it explains it better, but maybe we can > clean it up further. > > Also when I look at the example it certainly implies that > the parameters are > part of CLUE i.e. associated with the encoding rather than > CLUE referencing > an encoding defined elsewhere. > E.g. CLUE has: > encodeGroupID=EG0, maxGroupBandwidth=6000000 > encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60, > maxPps=124416000, maxBandwidth=4000000 > encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30, > maxPps=27648000, maxBandwidth=4000000 > encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30, > maxPps=15552000, maxBandwidth=4000000 > > Which to me at least implies they are all part of the same > syntax definition. > > Whereas to show that the parameters are defined outside > CLUE I would > expect something like: > Encoding Groups: > encodeGroupID=EG0, maxGroupBandwidth=6000000 > encodeID=ENC0 > encodeID=ENC1 > encodeID=ENC2 > > Encodings: > m=video > label=ENC0 > a=maxWidth:1920 > a=maxHeight:1088 > ... > m=video > label=ENC1 > a=maxWidth:1280 > a=maxHeight:720 > ... > etc. > > The above SDP isn't correct but I'm just try to illustrate > that it would be good > to show the define of the parameters separate from the > definition of the > encoding groups. It could be abstracted not to have SDP. > > [Duckworth, Mark] I understand. I guess it depends on how much > "syntax detail" you want to show in the examples, even though > it isn't really proper CLUE data model or protocol or SDP > syntax at all. My view is the example is okay as is, without > adding more syntax detail. I thought the working group agreed > in general these framework examples should be fairly high > level and not get bogged down in syntax. > [Duckworth, Mark] Does anybody else have input about this? > > Regards, > Mark > > -----Original Message----- > From: Christian Groves > [mailto:Christian.Groves@nteczone.com > ] > Sent: Tuesday, December 03, 2013 5:50 PM > To: Duckworth, Mark; clue@ietf.org > > Subject: Re: [clue] Consensus call: Encoding > Limits - SDP or CLUE signaling? > > Hello Mark, > > I guess what I found confusing is that the > decision was with regards > to "Encoding Limits" (i.e. maximums) not encoding > parameters which I > agree we've previously thought as being in SDP. > The examples in the > framework also shows > maxWidth/maxHeight/maxFramerate/maxPps/maxBandwidth > against individual encodes. So the framework isn't > consistent on this. > > Regards, Christian > > On 4/12/2013 1:17 AM, Duckworth, Mark wrote: > > Hello Christian, > > I agree with Rob, and even further, I think > the Framework document > is > > already consistent with this approach, because it > has been our > working understanding for quite a while. > > This text from section 8.1 sums it up nicely: > "Individual Encoding parameters are > represented in SDP [RFC4566], > not in CLUE messages. For example, for a video > encoding using > H.26x compression technologies, this can > include parameters such > as: > . Maximum bandwidth; > . Maximum picture size in pixels; > . Maximum number of pixels to be processed per > second; > The bandwidth parameter is the only one that > specifically relates > to a CLUE Advertisement, as it can be further > constrained by the > maximum group bandwidth in an Encoding Group." > > Mark > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org > ] On Behalf > Of Christian > Groves > Sent: Monday, December 02, 2013 5:55 PM > To: clue@ietf.org > Subject: Re: [clue] Consensus call: > Encoding Limits - SDP or CLUE > > signaling? > > Hello Rob, > > So we'll keep the encoding group concept > but there will be no CLUE > encoding parameters (i.e. no > maxGroupBandwidth, maxWidth, maxPps > > etc)? > > Regards, Christian > > On 3/12/2013 3:29 AM, Robert Hansen wrote: > > Hi Christian, > > I don't think this affects Encoding > Groups - that concept will > still be in the framework and will > need to be expressed in CLUE > ADVERTISMENT messages, as that's > something that isn't well > expressible in SDP. The encoding > limits referred to are the > per-encoding > > limits. > > This reflects what we had been taking > as our working understanding > so far in things like the signalling > document, so shouldn't > involve a radical rethink. > > Rob > > On 02/12/2013 01:04, Christian Groves > wrote: > > Hello Mary, all, > > In general I'm OK with expressing > coding limits in SDP. However > I'm trying to understand what the > impact is to the CLUE framework > as a result of that decision. Does > that then mean the entire > encoding group concept (i.e. > section 8 and 9 (and relevant > examples)) are removed from the > framework and that a Capture > Encoding is now effectively a > CaptureID and reference to an SDP m- > > line? or? > > Regards, Christian > > On 30/11/2013 8:24 AM, Mary Barnes > wrote: > > HI all, > > As mentioned in the email > about the November 26th design > team > meeting, there was consensus > amongst those on the call that SDP > should be used for expressing > encoding limits for CLUE. Rob's > presentation had details as to > how it could be done using the > CLUE protocol, but it was > decided (amongst those on the > call) > that we should go with the SDP > approach for now and IF an issue > is encountered with that > approach as details are worked > we could > go back to the alternative > proposal outlined in those charts. > > To move forward, we want to > ensure that there is WG consensus > for using SDP for the encoding > limits. If anyone has any > concerns about that approach, > please post a note explaining why > no later than > > Dec > > 9th, 2013. If you weren't at > the design team meeting and would > > like > > to express your support for > the approach, that's also a > good idea. > > Regards, > Mary > As WG co-chair > > > _______________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Christian.Groves@nteczone.com Wed Dec 4 19:18:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E311AE21A for ; Wed, 4 Dec 2013 19:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYY-TNNWLkCx for ; Wed, 4 Dec 2013 19:18:45 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9B1AE013 for ; Wed, 4 Dec 2013 19:18:45 -0800 (PST) Received: from ppp118-209-3-225.lns20.mel4.internode.on.net ([118.209.3.225]:55096 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VoPRF-0005Fz-0U; Thu, 05 Dec 2013 14:17:17 +1100 Message-ID: <529FF08D.8080708@nteczone.com> Date: Thu, 05 Dec 2013 14:18:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> <529E62F2.7090101@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B26E6@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6048B26E6@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 03:18:49 -0000 Hello Mark, Thanks for the comments. Please see my replies below. Regards, Christian On 5/12/2013 10:09 AM, Duckworth, Mark wrote: > Hi Christian, > > I understand the reasoning you give for why these role attributes have value. But I don't see a strong reason why they are necessary for CLUE. I'm concerned it will distract us from more essential work. [CNG] I see these as just another attribute. I don't think the discussion holds up work on any other areas. These can progress in parallel. I see the "meeting roles" and "vCard" attributes as largely stand alone. The "conference roles" attribute I can see that there may be relationship with floor control that needs consideration. So we could delay on the "conference roles" if that's in the too hard basket. With regards to the strong reason I really think it becomes valuable in a multiple stream environment. Consider the heterogeneous use case that we considered for the MCC, i.e. A conference between endpoints with the following characteristics: Endpoint A - 4 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 3 screens, 3 cameras Endpoint D - 3 screens, 3 cameras Endpoint E - 1 screen, 1 camera Endpoint F - 2 screens, 1 cameras Endpoint G - 1 screen, 1 camera A MCU would get the following Advertisements: The Advertisements for such a scenario are described below. +-----------------------+---------------------------------+ | Capture Scene #1| Description=Endpoint x| +-----------------------|---------------------------------+ | VC1 | EncodingGroup=1| | VC2 | EncodingGroup=1| | VC3 | EncodingGroup=1| | CSE(VC1, VC2, VC3)|| +---------------------------------------------------------+ Table 19: Advertisement received at the MCU from Endpoints A to D +-----------------------+---------------------------------+ | Capture Scene #1| Description=Endpoint y| +-----------------------|---------------------------------+ | VC1| EncodingGroup=1| | CSE(VC1)|| +---------------------------------------------------------+ If the MCU then sends a Advertisement to Endpoint A with information about the sources: +=======================+=================================+ | Capture Scene #1| | +-----------------------|---------------------------------+ | VC4|| | VC5|| | VC6|| | CSE(VC4,VC5,VC6) || +=======================+=================================+ | Capture Scene #2| | +-----------------------|---------------------------------+ | VC7|| | VC8|| | VC9|| | CSE(VC7,VC8,VC9)|| +=======================+=================================+ | Capture Scene #3| | +-----------------------|---------------------------------+ | VC10|| | VC11|| | VC12|| | CSE(VC10,VC11,VC12) || +=======================+=================================+ | Capture Scene #4| | +-----------------------|---------------------------------+ | VC13|| | CSE(VC13)|| +=======================+=================================+ | Capture Scene #5| | +-----------------------|---------------------------------+ | VC14|| | CSE(VC14)|| +=======================+=================================+ | Capture Scene #6| | +-----------------------|---------------------------------+ | VC15|| | CSE(VC15)|| +=======================+=================================+ It then uses MCCs to advertise site switching: +=======================+=================================+ | Capture Scene #7| Description=Output3streammix| +-----------------------|---------------------------------+ | MCC1(VC4,VC7,VC10)| CaptureArea=Left| || MaxCaptures=1| || SynchronisationID=1| | | Policy=SoundLevel:0| || EncodingGroup=1| ||| | MCC2(VC5,VC8,VC11,| CaptureArea=Left| |VC13,VC14,VC15)| MaxCaptures=1| || SynchronisationID=1| || Policy=SoundLevel:0| || EncodingGroup=1| ||| | MCC3(VC6,VC9,VC12)| CaptureArea=Left| || MaxCaptures=1| || SynchronisationID=1| || Policy=SoundLevel:0| || EncodingGroup=1| ||| | CSE(MCC1,MCC2,MCC3) || +=======================+=================================+ Now on what basis does the Consumer decide which of the source captures it wants? There's no encodings for the sources so you couldn't rely on that. The attributes only tell spatial information/language etc not who or where the VC is actually from. This is why I think you need a structured way to present the information about endpoint/scenes and captures. I don't think simply leaving it up to a free text field such as "Description" is the best that we can do. We'd be relying on multiple endpoints in multiple locations/companies to have the same policy in setting the free text field. For example: Endpoint B & C my might both be in California and both set "California meeting room" as a description. That's not enough to determine that one endpoint belongs to Google and the other Cisco. That's where I think having a structured format. vCard is a common way of saying: VERSION:4.0 KIND:org ORG:Cisco ADR:;;;;California;;U.S.A END:VCARD) or: VERSION:4.0 KIND:org ORG:Google ADR:;;;;California;;U.S.A END:VCARD) The information is structured and clear. > > I don't understand the difference between the proposal for a "vCard" attribute and the "End point vCard" attribute. Can you explain? [CNG] The difference is the scope of what the vCards cover. The "End point vCard" would be based on the endpoint/Capture scene. The individual "vCard" would be based on those in the Capture. It would be possible for a Provider to provide a vCard about the endpoint,scene and location in a structured manner. Section 6.1.4/RFC6350 defines the "KIND" parameter which indicates what the vCard represents. It gives some examples, which i'll borrow below. Organisational and Geographic vCards are not required to provide individual name information. Which makes them useful when the name information isn't known. For example: The provider may be a endpoint that the marketing department of company ABC. So the provider could be configured to give this information as "organisational" vCard associated with the CaptureScene, i.e. CaptueScene1(vCard=BEGIN:VCARD VERSION:4.0 KIND:org FN:ABC Marketing ORG:ABC\, Inc.;North American Division;Marketing END:VCARD) In addition the Provider could send a vCard attribute associated with the Captures themselves about the person/people in the capture. VC1(vCard=BEGIN:VCARD VERSION:4.0 KIND:individual FN:Jane Doe ROLE:Executive ORG:ABC\, Inc.;North American Division;Marketing END:VCARD) > > Regarding vCard, have you thought about the impact to the CLUE data model and protocol? I skimmed through RFC6350, and as I understand it the vCard format is all UTF-8 text, but not XML. And it can be very large, particularly if it includes embedded audio and photographs. I wonder if this potentially large non-XML data will cause problems if we add it to a CLUE advertisement message. [CNG] Yes I've given some thought to that. There is actually an vCard XML Representation we could use, xCard [IETF RFC 6351]. I'm not conversant enough with XML schema to say how to tie the CLUE and vCard schema together. I wouldn't think using UTF-8 vs XML would make much difference to the size. I think the size is largely driven by how much information is in the vCard. For simple vCards such as the above examples I don't think its an issue. However where a Provider wants to communicate photos or audio then I agree it will become an issue. In these situations I think that we would recommend that the provider provides a URI to the data (which is allowed by vCard) rather than embedding the data. That way the Consumer could fetch the information if it wanted to. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Tuesday, December 03, 2013 6:02 PM >> To: clue@ietf.org >> Subject: Re: [clue] Roles >> >> Hello all, >> >> Does anyone have any more concerns or comments about the "roles" work? >> >> It would be good to get your comments as soon as possible so that I could >> either address then via the list or prepare slides for next week's design team >> meeting to address them. >> >> Regards, Christian >> >> On 25/11/2013 12:20 PM, Christian Groves wrote: >>> Hello all, >>> >>> I'd like to pick up the discussion on roles from the last CLUE WG >>> meeting and try and make some progress via email before the design >>> team meeting. >>> >>> First i'd like to clarify that "role" is not intended to be a single >>> attribute and it can have different meanings. My draft >>> (draft-groves-clue-role-clarifications-00) seeks to clarify and >>> provide a terminology to be more specific. I.e.: >>> 2.1. Meeting Roles >>> 2.2. Conference System Control Roles >>> 2.3. Institution type >>> 2.4. Person Name Title >>> 2.5. Person Occupation (Job Title) >>> 2.6. Organisation Name >>> 2.7. Meeting Specific Roles >>> >>> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the >>> draft. 2.1 and 2.7 have also been grouped by the draft. >>> >>> There has been some concern that "roles" overlap with floor control. >>> From the role categories above I believe this is only relevant for >>> "conference system control" roles. >>> >>> Secondly the intended purpose of including "roles" into CLUE is not >>> for conference control or rostering but is for the selection of >>> Scenes/Captures and may be used for any subsequent rendering decisions >>> like the other CLUE attributes. The focus of the CLUE work has been to >>> focus on selecting captures based on technical aspects (what) e.g. >>> spatial properties but I think we've missed a more important aspect >>> that captures will depict people or entities (who). As a consumer I'm >>> likely to be more interested in who rather than what. For example if I >>> have a limited system and have received an Advertisement advertising 3 >>> Captures(left/centre/right) and I have only one screen so must choose >>> one. One could choose the centre but this is a problem if my boss is >>> sitting in the left capture. >>> >>> Thirdly because CLUE enhances the support of multiple streams there is >>> likely to be a larger set of captures being advertised. Information >>> about sources scenes/captures including different combinations may be >>> sent to a consumer providing much more choice. Each of these >>> scenes/captures may have different role information. Rather than try >>> to implement role across several different methods and introduce >>> dependencies between CLUE and other methods (e.g. conference package >>> or SDP which have no Scene/capture/MCC concepts) it is most >>> straightforward to send the information where it is needed i.e. in CLUE. >>> >>> Fourthly we have included the "description" parameter at the Scene,CSE >>> and Capture level. I think people will use those as de-facto for >>> "role" type information e.g. Scene Description="Company X VIC meeting >>> room". Rather than have a completely unstructured usage of description >>> I think that having "role" type information provided in a structured >>> form (i.e. via vCard) will at least provide a consumer the ability to >>> do some intelligent processing/rendering of the information. By >>> allowing this "role" information to be sent in a structured way via >>> CLUE I think will be an enabler for some interesting services and >>> features. >>> >>> Finally to re-iterate what the proposal is from the draft: >>> 1. The addition of a capture attribute "Meeting Role" attribute >>> with values as per section 3.1 and 3.2. >>> 2. The addition of a capture attribute "Conference System >>> Control Role" attribute with values as per section 3.3. >>> 3. The addition of a capture attribute "vCard" that allows one >>> or more vCards according to [RFC6350] to be associated with a >>> capture. >>> 4. The addition of a capture attribute "End point vCard" that >>> allows a "group", "org" or "location" kind of vCard according >>> to section 6.1.4/[RFC6350] to be associated with a capture. >>> >>> Comments? >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From stephen.botzko@gmail.com Thu Dec 5 06:53:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF21AE007 for ; Thu, 5 Dec 2013 06:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsu_cYDU4uSf for ; Thu, 5 Dec 2013 06:53:07 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 24EEB1ADF9C for ; Thu, 5 Dec 2013 06:53:07 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id oy12so13637906veb.40 for ; Thu, 05 Dec 2013 06:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7VIAUJkRYoG2VT0UokM1VLrEa5uC+2scuyvZsGEqMA8=; b=SchS3N8rsuiuL7c6Wrs+4B9dp8nZjtEife5ZW0P+Clm1wAgA/OoOtIhtVAWfsaZTH4 DInZYDnFXUJCN+ULpyY7zRbLsw6lPhJZqMIIVVnjR/INtKOVeKdk1ENMz1+63Wk2WPLu 7EPCmc3JO/LjPoZpFPAB8aM2PP2utcDqI+HayrWtlx3McDDN11AwXEu002XL4JZRl/8r zsfjH634lCRFjevPMS6bXoTJ4mfx/f9kitxcWLtKwWcbpcsa+VmQxITAalU0uJA+oeQx 66FmYRDTnjtJW2v9jcUtoGO2gGd83/SF/1by635OwVK4Hg5Zx0KDqgpa9zhxt8ckyuj6 PsBg== MIME-Version: 1.0 X-Received: by 10.52.230.102 with SMTP id sx6mr53518017vdc.15.1386255183613; Thu, 05 Dec 2013 06:53:03 -0800 (PST) Received: by 10.220.187.68 with HTTP; Thu, 5 Dec 2013 06:53:03 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1294E040@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA1294E040@AZ-FFEXMB04.global.avaya.com> Date: Thu, 5 Dec 2013 09:53:03 -0500 Message-ID: From: Stephen Botzko To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=089e0111ae34c9d04604eccaaf60 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:53:09 -0000 --089e0111ae34c9d04604eccaaf60 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>The document talks about =91CLUE will not dictate=92, =91architecture fo= r CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wonder) I imagine other WGs have run into this with their requirements. How is it normally handled? Stephen On Tue, Dec 3, 2013 at 6:37 AM, Romascanu, Dan (Dan) wr= ote: > Minor clarification of my comment on a minor issue. What needs > definition here is the term CLUE itself. The document talks about =91CLUE > will not dictate=92, =91architecture for CLUE=92, =91CLUE enables=92, etc= ., but what > is CLUE? (someone may wonder) > > > > Regards, > > > > Dan > > > > > > > > > > > Minor issues: > > 1. If this is the first and basic document to be read by somebody who > starts to browse through the CLUE specifications, it would be good to > define or expand some place in the introduction what CLUE is. > > [SB] I am not sure if the CLUE WG has a recommended order for > reading the various documents. Personally I would recommend that people > start with the use cases. In any event, I think the document purpose is > properly captured in the abstract - it is not intended to be an > introduction to telepresence generally or as an orientation to CLUE > specifications. > [/SB] > > > > > > > --089e0111ae34c9d04604eccaaf60 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
>>>The document t= alks about =91CLUE will not dictate=92, =91architecture for CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wond= er)
I imagine other WGs have run into this with their requirement= s.=A0 How is it normally handled?

Stephen


On Tue, Dec 3, 2013 at 6:37 AM, Romascanu, D= an (Dan) <dromasca@avaya.com> wrote:

Minor clarification = of my comment on a minor issue. What needs definition here is the term CLUE= itself. The document talks about =91CLUE will not dictate=92, =91architect= ure for CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wond= er)

=A0

Regards,

=A0

Dan

=A0

=A0

=A0

=A0


Minor issues:

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

[SB] I am not sure if the CLUE WG has a recommended = order for reading the various documents.=A0 Personally I would recommend th= at people start with the use cases.=A0 In any event, I think the document p= urpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as= an orientation to CLUE specifications.
[/SB]

=A0

=A0

=A0<= /u>


--089e0111ae34c9d04604eccaaf60-- From pkyzivat@alum.mit.edu Thu Dec 5 07:43:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59D11AE074 for ; Thu, 5 Dec 2013 07:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGHaN2rzEbsF for ; Thu, 5 Dec 2013 07:43:56 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id BFADF1AE064 for ; Thu, 5 Dec 2013 07:43:55 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id xqrH1m0051vXlb856rjs17; Thu, 05 Dec 2013 15:43:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id xrjs1m0013ZTu2S3drjstw; Thu, 05 Dec 2013 15:43:52 +0000 Message-ID: <52A09F37.9000003@alum.mit.edu> Date: Thu, 05 Dec 2013 10:43:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: clue@ietf.org References: <5292A5CE.4050605@nteczone.com> <529E62F2.7090101@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D6048B26E6@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D6048B26E6@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386258232; bh=zBnK0cwR2v5hD3KPJs4LPWaCuw3Osu7is3/c8tMqqCQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pKdArvcjQJcquKXBP2d/9dX7sHEM3YuYrCMnr5IO1TJtLN+FbgFVuh4tbQjb2hD3K /f8nLXogjBHmZXmL6XawsaDkZSS6wf0UY1XVVJj1ay3zk0GbuEJHJBYmk9fQkxkgwi ONgJdc9HLiEntvYzpyBrebdrqmogIMUEmqpdiBTRm40ko3899/hYYubfJiut033rpr TK6iVjpvJSRfjw8Q2OyXJozbmiMghKVeyWEcDaZyW4szhFZqJTRuJhLJjA/meuyLmk BNLnIqB4XA8ZxMKGQzJkt4yRUG/TLhrYX53b3DKvaI9rg2pLgkHLpIF6HRnMiy11A7 DW2FvrUyeTG2g== Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:43:57 -0000 I have the impression that there is also a definition for an xCard, that is like a vCard, but represented in XML. If that really exists it might be a better fit. On 12/4/13 6:09 PM, Duckworth, Mark wrote: > Hi Christian, > > I understand the reasoning you give for why these role attributes have value. But I don't see a strong reason why they are necessary for CLUE. I'm concerned it will distract us from more essential work. > > I don't understand the difference between the proposal for a "vCard" attribute and the "End point vCard" attribute. Can you explain? > > Regarding vCard, have you thought about the impact to the CLUE data model and protocol? I skimmed through RFC6350, and as I understand it the vCard format is all UTF-8 text, but not XML. And it can be very large, particularly if it includes embedded audio and photographs. I wonder if this potentially large non-XML data will cause problems if we add it to a CLUE advertisement message. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Tuesday, December 03, 2013 6:02 PM >> To: clue@ietf.org >> Subject: Re: [clue] Roles >> >> Hello all, >> >> Does anyone have any more concerns or comments about the "roles" work? >> >> It would be good to get your comments as soon as possible so that I could >> either address then via the list or prepare slides for next week's design team >> meeting to address them. >> >> Regards, Christian >> >> On 25/11/2013 12:20 PM, Christian Groves wrote: >>> Hello all, >>> >>> I'd like to pick up the discussion on roles from the last CLUE WG >>> meeting and try and make some progress via email before the design >>> team meeting. >>> >>> First i'd like to clarify that "role" is not intended to be a single >>> attribute and it can have different meanings. My draft >>> (draft-groves-clue-role-clarifications-00) seeks to clarify and >>> provide a terminology to be more specific. I.e.: >>> 2.1. Meeting Roles >>> 2.2. Conference System Control Roles >>> 2.3. Institution type >>> 2.4. Person Name Title >>> 2.5. Person Occupation (Job Title) >>> 2.6. Organisation Name >>> 2.7. Meeting Specific Roles >>> >>> Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the >>> draft. 2.1 and 2.7 have also been grouped by the draft. >>> >>> There has been some concern that "roles" overlap with floor control. >>> From the role categories above I believe this is only relevant for >>> "conference system control" roles. >>> >>> Secondly the intended purpose of including "roles" into CLUE is not >>> for conference control or rostering but is for the selection of >>> Scenes/Captures and may be used for any subsequent rendering decisions >>> like the other CLUE attributes. The focus of the CLUE work has been to >>> focus on selecting captures based on technical aspects (what) e.g. >>> spatial properties but I think we've missed a more important aspect >>> that captures will depict people or entities (who). As a consumer I'm >>> likely to be more interested in who rather than what. For example if I >>> have a limited system and have received an Advertisement advertising 3 >>> Captures(left/centre/right) and I have only one screen so must choose >>> one. One could choose the centre but this is a problem if my boss is >>> sitting in the left capture. >>> >>> Thirdly because CLUE enhances the support of multiple streams there is >>> likely to be a larger set of captures being advertised. Information >>> about sources scenes/captures including different combinations may be >>> sent to a consumer providing much more choice. Each of these >>> scenes/captures may have different role information. Rather than try >>> to implement role across several different methods and introduce >>> dependencies between CLUE and other methods (e.g. conference package >>> or SDP which have no Scene/capture/MCC concepts) it is most >>> straightforward to send the information where it is needed i.e. in CLUE. >>> >>> Fourthly we have included the "description" parameter at the Scene,CSE >>> and Capture level. I think people will use those as de-facto for >>> "role" type information e.g. Scene Description="Company X VIC meeting >>> room". Rather than have a completely unstructured usage of description >>> I think that having "role" type information provided in a structured >>> form (i.e. via vCard) will at least provide a consumer the ability to >>> do some intelligent processing/rendering of the information. By >>> allowing this "role" information to be sent in a structured way via >>> CLUE I think will be an enabler for some interesting services and >>> features. >>> >>> Finally to re-iterate what the proposal is from the draft: >>> 1. The addition of a capture attribute "Meeting Role" attribute >>> with values as per section 3.1 and 3.2. >>> 2. The addition of a capture attribute "Conference System >>> Control Role" attribute with values as per section 3.3. >>> 3. The addition of a capture attribute "vCard" that allows one >>> or more vCards according to [RFC6350] to be associated with a >>> capture. >>> 4. The addition of a capture attribute "End point vCard" that >>> allows a "group", "org" or "location" kind of vCard according >>> to section 6.1.4/[RFC6350] to be associated with a capture. >>> >>> Comments? >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Dec 5 08:15:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A31AE0C5 for ; Thu, 5 Dec 2013 08:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kharZ7-8mDdj for ; Thu, 5 Dec 2013 08:15:44 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7B12C1AE028 for ; Thu, 5 Dec 2013 08:15:44 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so1107961wib.5 for ; Thu, 05 Dec 2013 08:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/LrwrEx41B1HtH/oDCX0flvzPGoVFHGGxdE6movgWXQ=; b=lfkPDeJdT7MdlMnzZnX+nkIImcwrxlb7KlSFufdCSsDDfURZG13MG+WOBD7+bgQJyK Q3/JOazfQkS3pqOJKxAtd3kz5qg4GKd8GaXzB3IJBNkFop94AWiqvqviXIJkKlKmc3tM 6/zSakhqvGVgJFerVO85BNP5+8AUE9pUY57+6BQzWfPRX4RqOLTN4CIQxOT6nCMBphUL AB4hEU6ZatpAn1IDN1Eo/UeeSCjXwzfEajHzMm5UREtqBMPD657tMnVdrj/p3tGpTvHH Q6T5S276AZbo/wZSdcOC69IPp5XCyElvFB3kFTHbxWGUlTntlx7bAmPMk4jiwxAn7EIV /iLA== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr70806689wjc.9.1386260140646; Thu, 05 Dec 2013 08:15:40 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 5 Dec 2013 08:15:40 -0800 (PST) In-Reply-To: References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <9904FB1B0159DA42B0B887B7FA8119CA1294E040@AZ-FFEXMB04.global.avaya.com> Date: Thu, 5 Dec 2013 10:15:40 -0600 Message-ID: From: Mary Barnes To: Stephen Botzko Content-Type: multipart/alternative; boundary=047d7b873a103fe48404eccbd7b2 Cc: "clue@ietf.org" , "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:15:47 -0000 --047d7b873a103fe48404eccbd7b2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We can expand CLUE on first usage and then qualify that the use of the term CLUE in this document is referring to the solutions developed to enable support for CLUE. It may be most appropriate actually to introduce the term CLUE in the abstract. Perhaps something like: OLD This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and related definitions are also covered herein. NEW This memo discusses the requirements for specifications, that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. Mary On Thu, Dec 5, 2013 at 8:53 AM, Stephen Botzko wr= ote: > >>>The document talks about =91CLUE will not dictate=92, =91architecture = for > CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wonder) > I imagine other WGs have run into this with their requirements. How is i= t > normally handled? > > Stephen > > > > On Tue, Dec 3, 2013 at 6:37 AM, Romascanu, Dan (Dan) = wrote: > >> Minor clarification of my comment on a minor issue. What needs >> definition here is the term CLUE itself. The document talks about =91CLU= E >> will not dictate=92, =91architecture for CLUE=92, =91CLUE enables=92, et= c., but what >> is CLUE? (someone may wonder) >> >> >> >> Regards, >> >> >> >> Dan >> >> >> >> >> >> >> >> >> >> >> Minor issues: >> >> 1. If this is the first and basic document to be read by somebody who >> starts to browse through the CLUE specifications, it would be good to >> define or expand some place in the introduction what CLUE is. >> >> [SB] I am not sure if the CLUE WG has a recommended order for >> reading the various documents. Personally I would recommend that people >> start with the use cases. In any event, I think the document purpose is >> properly captured in the abstract - it is not intended to be an >> introduction to telepresence generally or as an orientation to CLUE >> specifications. >> [/SB] >> >> >> >> >> >> >> > > --047d7b873a103fe48404eccbd7b2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
We can expand CLUE on first usage and then qualify that th= e use of the term CLUE in this document is referring to the solutions devel= oped to enable support for CLUE. =A0

It may be most appr= opriate actually to introduce the term CLUE in the abstract. Perhaps someth= ing like:=A0
OLD
=A0 =A0=A0This= memo discusses the requirements for specifications that enable
   telepresence interoperability, by describing the relationship betwe=
en
   multiple RTP streams.  In addition, the problem statement and related
   definitions are also covered herein.
NEW
   This memo discusses the requirements for specifications=
, that enable
   telepresence interoperability by describing behaviors and protocols     for=
=A0Controlling Multiple Streams for Telepresence (CLUE). =A0
   In addition, the problem statement and=
 related
   definitions are also covered herein.

Mary

On Thu, Dec 5, 2013 at 8:53 AM, Stephen Botzko <stephen.botzko@= gmail.com> wrote:
>>&= gt;The document talks about =91CLUE will no= t dictate=92, =91architecture for CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wond= er)
I imagine other WGs have run into this with their requi= rements.=A0 How is it normally handled?

Stephen



On Tue, Dec 3, 2013 at 6:37 AM, Romascanu, D= an (Dan) <dromasca@avaya.com> wrote:

Minor clarification = of my comment on a minor issue. What needs definition here is the term CLUE= itself. The document talks about =91CLUE will not dictate=92, =91architect= ure for CLUE=92, =91CLUE enables=92, etc., but what is CLUE? (someone may wond= er)

=A0

Regards,

=A0

Dan

=A0

=A0

=A0

=A0


Minor issues:

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

[SB] I am not sure if the CLUE WG has a recommended = order for reading the various documents.=A0 Personally I would recommend th= at people start with the use cases.=A0 In any event, I think the document p= urpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as= an orientation to CLUE specifications.
[/SB]

=A0

=A0

=A0<= /u>



--047d7b873a103fe48404eccbd7b2-- From mary.ietf.barnes@gmail.com Thu Dec 5 11:09:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0461AE167 for ; Thu, 5 Dec 2013 11:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7StMGCbCOK7M for ; Thu, 5 Dec 2013 11:09:11 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9390B1AE0E4 for ; Thu, 5 Dec 2013 11:09:10 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so153923wib.9 for ; Thu, 05 Dec 2013 11:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=10dNffZXDJ6HWCxpZVgDFBRPgsArtYDzA6QhF1szfvw=; b=q6Ww5ANHbfLVKMi/NyTmzUusXtEDRUpLpExCf+/XV+rIajHAVVe5AI0OgItRG1vO4U 5Iuh5gvENlBBYYQG5IgDlWmzAV3zv6fpdCIeJOk/C0jiD3r8yKDPq9V1eTnnJ/plnoPD SuZLlncQTR5aB3eY6OUuEq8QUtyxcXsTN2zNKEJgiNALrXSVoN9iirKxO6j973boxQfB zQgZOEPyxrxsKlI3RpLTfMVQvUlC9+jNDpOcHxH0HOLlMUTH64FeBBVc17gVd2nxSVT/ yQ3lNQ1VSCfCiBz659UgzWaRgLOsiHaLLUJlouc34x3RoAvj79Y07akJKZDJYcFL1ZGv nJ4A== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr289618wic.36.1386270546452; Thu, 05 Dec 2013 11:09:06 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 5 Dec 2013 11:09:06 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 5 Dec 2013 13:09:06 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7b6242527c35a204ecce4337 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:09:19 -0000 --047d7b6242527c35a204ecce4337 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable HI Michael, Comments inline below [MB]. Thanks, Mary. On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer wrote: > Requirement 15 is written in language that is more vague than the other > requirements. > > I would argue that what it says is already covered by the other > requirements and could be removed with no harm. > [MB] You have a reasonable point, but I would suggest that leaving this requirement also causes no harm. It's been in the document since the -00 WG version. It was added as REQMT-16 in the individual -03. Please keep in mind that this document has completed IETF Last Call (we had consensus on this document in the WG a while back), so there would have to an extremely compelling reason and WG consensus to remove. [/MB] > > > For example Reqts 2 and 4 seem to say that there will be multiple devices > involved in creating a =93presentation=94. > > And 5-9 seem to cover various interop issues with different numbers and > types of devices. > > Also, presentation is not defined. > [MB] Given that we have an entire use case dedication to "presentation" I don't think the term needs to be defined in this document. However, it would probably be good to add the reference to the Presentation use case for REQMT-15 as we have done for some others. [/MB] > > > Mike > > > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mar= k > *Sent:* Monday, December 02, 2013 3:11 PM > *To:* Stephen Botzko; Mary Barnes > > *Cc:* draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; > clue@ietf.org > *Subject:* Re: [clue] Gen-ART review of > draft-ietf-clue-telepresence-requirements-06.txt > > > > Comments inline. > > Mark Duckworth > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephen Botzko > *Sent:* Wednesday, November 27, 2013 5:28 PM > *To:* Mary Barnes > *Cc:* draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; > clue@ietf.org > *Subject:* Re: [clue] Gen-ART review of > draft-ietf-clue-telepresence-requirements-06.txt > > > > Dan - thanks so much for reviewing this. > > Comments are in-line > > > > Stephen Botzko > > > > On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes > wrote: > > On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat > wrote: > > Authors, > > What do you think of these comments? > If you aren't in agreement with all of them, then we should have a dialog > with Dan about them. > > If in agreement, then lets discuss what changes are appropriate. > > More inline. > > > > On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-clue-telepresence-requirements-06.txt > Reviewer: Dan Romascanu > Review Date: 11/21/13 > IETF LC End Date: 11/27/13 > IESG Telechat date: (if known) > > Summary: It's a good and well written document, almost ready, but a numbe= r > of issues should be clarified before approval. > > Major issues: > > 1. The definitions of Left and Right in Section 3 use an entry article in > Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of > Wikipedia articles (subject to change, subject to attacks) as references, > and I also believe that the current definitions (@11/21/13, US morning > hours) are ambiguous. Actually the Wikipedia article does not include > definitions for Left and Right, and speaks about 'house left' (equal to > 'stage right') and 'house right' (equal to 'stage left'). If another > specification in CLUE will use the terms defined here it is not clear whi= ch > one is meant. > > > > This seems like a reasonable point to me. Is there a more stable referenc= e > we can use? If not, can we just define these terms in the document? > > [MB] I'm almost of a mind to just remove those definitions. The consensu= s > was that the terms should be qualified when they are used and the framewo= rk > does an excellent job of defining more precise terms that properly qualif= y > "left" and "right" and differentiate from stage right, etc. as appropriat= e. > We use "left" and "right" in one place in this requirements document and= I > think the use is general enough that we don't need a definition (in this > document). The wikipedia reference has been in the document since day 1 > as a WG document (it was added in -03 of the individual document). The > discussions around "left"/"right" on the list were in the context of the > definitions document and again, consensus was that the terms should be > qualified (as they are in the framework), thus I don't think the current > definitions serve any value. [/MB] > > [SB] I agree with Mary that these definitions can simply be removed. > [/SB] > > *[Duckworth, Mark] I agree too.* > > > > 2. In REQMT-1d it is not clear what 'the extent of individual video > captures' means > > 3. In REQMT-2d it is not clear what 'the extent of individual audio > captures' means > > > > We have had our own concerns about this. I think we want to say > *something* but its unclear to me exactly what. Perhaps we could focus on > what we want to use this for, and explicitly leave details of what it is > for the FW. > > [MB] Can you point to the threads of discussion where you feel this > concern with this phrasing has been raised? There were certainly concer= ns > raised about those requirements (i.e., 3D), but I'm not reading this as > Dan's concern. My understanding is that the word "extent" is used in th= e > context of video imagery from the perspective of the camera - i.e., the > "angular extent" or something like that. I think we should replace the > word "extent" with something more specific. Anyone have a suggestion? > > [SB] > > The intent of REQMT-1d was to say that CLUE needs to identify the area > that each camera captured in the room - so it would be clear how views fr= om > different camera related to each other, and also if there were any gaps, > etc. Identifying the scale of the view is related, but is captured > concisely in requirement 6. Proper rendering in a multi-camera > telepresence system requires this knowledge - today it is generally > hard-wired into the room design. But that doesn't result in an > interoperable experience, and it needs to be signaled if you want to get > appropriate rendering between rooms with disparate designs. > > > > For audio [REQMT-2d], there is an analogous need to identify the area of > coverage of a microphone. The need to correlate the audio and the video = is > related, but is captured separately in REQMT-3. > > > > The discussions on the list related to audio and video area of coverage > were about whether the model in the framework was adequate. Personally I > believe it is. But what really matters here is whether we are clearly > stating the *requirement*, not the adequacy of the proposed > specifications. > > One alternative term is "area of coverage", which is commonly used in > surveillance applications to describe a similar concept. If people think > that might be confused with radio coverage (e.g. an LTE coverage map) we > could draft a definition and add it to section 3. > > [/SB] > > *[Duckworth, Mark] I agree with Steve about the intent. I agree =93area = of > coverage=94 is a better term than =93extent=94 for this purpose.* > > > > > > And, note these requirements were added based on discussion at IETF-82: > > http://www.ietf.org/proceedings/82/slides/clue-1.pdf > > > > [/MB] > > Thanks, > Paul > > > > 4. REQMT-10: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a > telepresence session with those that do. > > More clarity is needed to explain what level of participation in a sessio= n > (and what limitations) are expected from endpoints that do not support th= e > telepresence extensions. I assume there are limitations, otherwise > extensions would not be needed. > > [SB] The intent was to simply state that the solution must not prevent > direct interoperability with SIP devices (either phone or > videoconferencing) - without the need for a middlebox to convert signalin= g > (as would be required with rtcweb for instance). The limitation is simp= ly > that telepresence extensions can't be used. I do not see a need to > describe the limitations of existing SIP systems in this requirements > document. > > Suggested text that makes the requirement more clear would be helpful. > This is a bit tricky to word, since SIP itself has no requirement that sa= ys > SIP endpoints must interoperate with each other w/o middleboxes to assist= . > And in fact they often don't. We could alternatively drop the requiremen= t. > > [/SB] > > *[Duckworth, Mark] I agree with Steve about the intent. How about > something like =93The solution must make it possible for devices that sup= port > CLUE to interoperate directly with SIP devices that do not support CLUE= =94 ?* > > > 5. REQMT-15 (last bullet): I could not really figure out what is meant he= re > > * There can be variation in placement, number and size of > presentations > > [SB]At this point I am not certain either. We might have meant that > different use cases had different placements, number, and size of > presentations. Or that existing telepresence systems handle presentations > in different ways. > > It is not worded as a clear requirement, and it says "can", not "should" > or "must". My recommendation is to delete that bullet. > [/SB] > > *[Duckworth, Mark] I think we meant this:* > > * - There can be multiple simultaneous presentation media > streams* > > *- Presentation media streams can be spatially related to > each other* > > > > 6. REQMT-16: The solution MUST include extensibility mechanisms. > > What 'extensibility' is meant here? Extending the telepresence sessions, > or extending the specifications for new functionality in the future? > > [SB] What is meant is extending the specifications for new functionality > in the future. I suggest that we re-word to "New protocols developed for > the solution MUST include extensibility mechanisms" > [/SB] > > *[Duckworth, Mark] Steve=92s suggestion is more clear.* > > > > Minor issues: > > 1. If this is the first and basic document to be read by somebody who > starts to browse through the CLUE specifications, it would be good to > define or expand some place in the introduction what CLUE is. > > [SB] I am not sure if the CLUE WG has a recommended order for reading the > various documents. Personally I would recommend that people start with t= he > use cases. In any event, I think the document purpose is properly captur= ed > in the abstract - it is not intended to be an introduction to telepresenc= e > generally or as an orientation to CLUE specifications. > [/SB] > > *[Duckworth, Mark] I agree.* > > > > 2. In the Introduction Section I see: > > These > > requirements are for the specification, they are not requirements on > the telepresence systems implementing the solution/protocol that will > be specified. > > But then all requirements in section 5 start by 'The solution ...' which > is ambiguous. It would be good to mention (again) in section 5 that by wh= at > is meant by the 'solution' is the definition of the protocol, not the > implementation. > > [SB] I agree. We should also use "specifications", since current plans > call for more than one standards-track RFC > [/SB] > > *[Duckworth, Mark] I agree* > > > 3. I will defer to the Security Review to comment whether REQMT-18 is > enough from a security point of view - especially as the information abou= t > media captures may include explicitly or implicitly details about equipme= nt > on each site, etc. To me it seems a little bit too vague. > > [SB] I don't see it as vague - it pretty clearly says that only the > mechanism needs to be secure. I think you are saying that the security > section might be incomplete. > > Current protocol designs do not include explicit details about equipment, > and I see nothing in the requirements that suggest otherwise. Some > requirements do require transport of information that can be used infer > room dimensions (at least of the visible portion of the room) and the > audio/video coverage within it. Can you identify threats that might use > that information? > > Of course each specification includes its own Security Considerations. > Obviously we will address any security review comments in this one. > [/SB]. > > > Regards, > > Dan > > > --047d7b6242527c35a204ecce4337 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
HI Michael,

Comments inline below [MB].=

Thanks,
Mary.


On Mon, Dec 2, 2013 at 2:34 PM, Mic= hael Hammer <michael.hammer@yaanatech.com> wrote:=

Requirement 1= 5 is written in language that is more vague than the other requirements.=

I would argue that what i= t says is already covered by the other requirements and could be removed wi= th no harm.

[MB] You have a reasonable point, but I= would suggest that leaving this requirement also causes no harm. It's = been in the document since the -00 WG version. =A0It was added as REQMT-16 = in the individual -03.
Please keep in mind that this document has completed IETF Last C= all (we had consensus on this document in the WG a while back), so there wo= uld have to an extremely compelling reason and WG consensus to remove. =A0<= br>
[/MB]

=A0<= /p>

For example Reqts 2 an= d 4 seem to say that there will be multiple devices involved in creating a = =93presentation=94.

And 5-9 seem to cover var= ious interop issues with different numbers and types of devices.<= /u>

Also, presentation is not= defined.

[MB] Given that we = have an entire use case dedication to "presentation" I don't = think the term needs to be defined in this document. However, it would prob= ably be good to add the reference to the Presentation use case for REQMT-15= as we have done for some others. =A0 [/MB]

=A0<= /p>

Mike

=A0<= /p>

=A0

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Monday, December 02, 2013 3:11 PM
To: Stephen Botzko= ; Mary Barnes


Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-r= equirements-06.txt

=A0

Comments inline.

Mark Duckworth<= /u>

=A0<= u>

From:= clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen = Botzko
Sent: Wednesday, November 27, 2013 5:28 PM
To: Mary Barnes=
Cc: draft-ietf-clue-telepresence-requirem= ents.all@tools.ietf.org; clue@ietf.org
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-r= equirements-06.txt

=A0

Dan - thanks so much fo= r reviewing this.

Comments are in-line

= =A0

Stephen Botzko

=A0

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wr= ote:

On Thu, Nov 21,= 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Authors,

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

If in agreement, then lets discuss what chan= ges are appropriate.

More inline.



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

<= p class=3D"MsoNormal">I am the assigned Gen-ART reviewer for this draft. Fo= r background on Gen-ART, please see the FAQ at

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

Please resolve these comments along with any other Last Call comments y= ou may receive.

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

Summary: It's a good and well wri= tten document, almost ready, but a number of issues should be clarified bef= ore approval.

Major issues:

1. The definitions of Left and Ri= ght in Section 3 use an entry article in Wikipedia ('Stage Directions&#= 39;). I am both uncomfortable with the usage of Wikipedia articles (subject= to change, subject to attacks) as references, and I also believe that the = current definitions (@11/21/13, US morning hours) are ambiguous. Actually t= he Wikipedia article does not include definitions for Left and Right, and s= peaks about 'house left' (equal to 'stage right') and '= house right' (equal to 'stage left'). If another specification = in CLUE will use the terms defined here it is not clear which one is meant.=

=A0

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

[MB] I'm almost of a min= d to just remove those definitions. =A0The consensus was that the terms sho= uld be qualified when they are used and the framework does an excellent job= of defining more precise terms that properly qualify "left" and = "right" and differentiate from stage right, etc. as appropriate. = =A0We use "left" and "right" in one place in this requi= rements document and I think the use is general enough that we don't ne= ed a definition (in this document). =A0 The wikipedia reference has been in= the document since day 1 as a WG document (it was added in -03 of the indi= vidual document). =A0 The discussions around "left"/"right&q= uot; on the list were in the context of the definitions document and again,= consensus was that the terms should be qualified (as they are in the frame= work), thus I don't think the current definitions serve any value.=A0[/= MB]=A0

[SB] I agree with Mary = that these definitions can simply be removed.
[/SB]

[Duckworth, Mark] I ag= ree too.

=A0<= /p>

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

3. In REQMT-2d it is not cle= ar what 'the extent of individual audio captures' means

=A0

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

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

[SB]

The intent of REQMT-1d was to= say that CLUE needs to identify the area that each camera captured in the = room - so it would be clear how views from different camera related to each= other, and also if there were any gaps, etc.=A0 Identifying the scale of t= he view is related, but is captured concisely in requirement 6.=A0 Proper r= endering in a multi-camera telepresence system requires this knowledge - to= day it is generally hard-wired into the room design.=A0 But that doesn'= t result in an interoperable experience, and it needs to be signaled if you= want to get appropriate rendering between rooms with disparate designs.=

=A0

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

=A0

The discussions on the list r= elated to audio and video area of coverage were about whether the model in = the framework was adequate.=A0 Personally I believe it is.=A0 But what real= ly matters here is whether we are clearly stating the requirement, n= ot the adequacy of the proposed specifications.=A0

One alternative term is "area of cov= erage", which is commonly used in surveillance applications to describ= e a similar concept.=A0 If people think that might be confused with radio c= overage (e.g. an LTE coverage map) we could draft a definition and add it t= o section 3.

[/SB]

[Duckworth, Mark] I agree with Steve = about the intent.=A0 I agree =93area of coverage=94 is a better term than = =93extent=94 for this purpose.=

=A0

=

=A0

And, note these requirements were added based on discussi= on at IETF-82:

=A0<= u>

=A0[/MB]

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

=A0

=

4. REQMT-10: The solution MUST make it possible for = endpoints without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support for telepresenc= e extensions to participate in a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0telepresence session with those that do.
=
More clarity is needed to explain what level of participation in a sess= ion (and what limitations) are expected from endpoints that do not support = the telepresence extensions. I assume there are limitations, otherwise exte= nsions would not be needed.

[SB] The intent was to simply state that = the solution must not prevent direct interoperability with SIP devices (eit= her phone or videoconferencing) - without the need for a middlebox to conve= rt signaling (as would be required with rtcweb for instance). =A0 The limit= ation is simply that telepresence extensions can't be used.=A0 I do not= see a need to describe the limitations of existing SIP systems in this req= uirements document.=A0

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

[/SB]

[Duckworth, Mark] I agree with Steve = about the intent.=A0 How about something like =93The solution must make it = possible for devices that support CLUE to interoperate directly with SIP de= vices that do not support CLUE=94 ?


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

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

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

It is not worded as a clear requirement, and it says "can", n= ot "should" or "must".=A0 My recommendation is to delet= e that bullet.
[/SB]

[Duckworth, Mark] I think we meant this:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0- There can be multiple simul= taneous presentation media streams

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 -= Presentation media streams can be spatially related to each other

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 <= u>=A0

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

What 'extensibility' is meant here? Extending the telepresence = sessions, or extending the specifications for new functionality in the futu= re?

[SB] What is mea= nt is extending the specifications for new functionality in the future.=A0 = I suggest that we re-word to "New protocols developed for the solution= MUST include extensibility mechanisms"
[/SB]

[Duckworth, Mark] Steve=92s suggestion is more clear.



Minor issues:

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

[SB] I am not sure if the CLUE WG has a r= ecommended order for reading the various documents.=A0 Personally I would r= ecommend that people start with the use cases.=A0 In any event, I think the= document purpose is properly captured in the abstract - it is not intended= to be an introduction to telepresence generally or as an orientation to CL= UE specifications.
[/SB]

[Duckworth, Mark] I agree.=

=A0

=

2. In the Introductio= n Section I see:

=A0 These

=A0 =A0 requirements are for the specificat= ion, they are not requirements on
=A0 =A0 the telepresence systems implementing the solution/protocol that wi= ll
=A0 =A0 be specified.

But then all requirements in section 5 s= tart by 'The solution ...' which is ambiguous. It would be good to = mention (again) in section 5 that by what is meant by the 'solution'= ; is the definition of the protocol, not the implementation.<= /p>

[SB] I agree.=A0 We should also use "= ;specifications", since current plans call for more than one standards= -track RFC
[/SB]

[Duckworth, Mark] I agree=


3. I will defer to the S= ecurity Review to comment whether REQMT-18 is enough from a security point = of view - especially as the information about media captures may include ex= plicitly or implicitly details about equipment on each site, etc. To me it = seems a little bit too vague.

[SB] I don= 't see it as vague - it pretty clearly says that only the mechanism nee= ds to be secure.=A0 I think you are saying that the security section might = be incomplete.

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

Of course = each specification includes its own Security Considerations. Obviously we w= ill address any security review comments in this one.
[/SB].


Regards,

Dan

=A0


--047d7b6242527c35a204ecce4337-- From michael.hammer@yaanatech.com Thu Dec 5 11:36:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2D01AE018 for ; Thu, 5 Dec 2013 11:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JloF9jdnc6j4 for ; Thu, 5 Dec 2013 11:36:16 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2F1A802A for ; Thu, 5 Dec 2013 11:36:16 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 5 Dec 2013 11:36:13 -0800 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: AQHO8e160rMmBBgWBU+3CE7PxRpYCJpF/Wtw Date: Thu, 5 Dec 2013 19:36:12 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF01ECB@sc9-ex2k10mb1.corp.yaanatech.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.52] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CF_01CEF1C7.576B5180" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:36:25 -0000 ------=_NextPart_000_00CF_01CEF1C7.576B5180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D0_01CEF1C7.576B5180" ------=_NextPart_001_00D0_01CEF1C7.576B5180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mary, What is the process here? The earlier comments imply that further changes may be needed and possible. Now, you say no changes are possible? What was the point of posting on the email list? Or, is it only comments from the anointed? The anointed are free to use my comments how they like by the way. :) I would also argue since the text is redundant, it is editorial change to remove to make the document clearer. Mike From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, December 05, 2013 2:09 PM To: Michael Hammer Cc: Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt HI Michael, Comments inline below [MB]. Thanks, Mary. On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer wrote: Requirement 15 is written in language that is more vague than the other requirements. I would argue that what it says is already covered by the other requirements and could be removed with no harm. [MB] You have a reasonable point, but I would suggest that leaving this requirement also causes no harm. It's been in the document since the -00 WG version. It was added as REQMT-16 in the individual -03. Please keep in mind that this document has completed IETF Last Call (we had consensus on this document in the WG a while back), so there would have to an extremely compelling reason and WG consensus to remove. [/MB] For example Reqts 2 and 4 seem to say that there will be multiple devices involved in creating a "presentation". And 5-9 seem to cover various interop issues with different numbers and types of devices. Also, presentation is not defined. [MB] Given that we have an entire use case dedication to "presentation" I don't think the term needs to be defined in this document. However, it would probably be good to add the reference to the Presentation use case for REQMT-15 as we have done for some others. [/MB] Mike From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, December 02, 2013 3:11 PM To: Stephen Botzko; Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Comments inline. Mark Duckworth From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, November 27, 2013 5:28 PM To: Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Dan - thanks so much for reviewing this. Comments are in-line Stephen Botzko On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes wrote: On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat wrote: Authors, What do you think of these comments? If you aren't in agreement with all of them, then we should have a dialog with Dan about them. If in agreement, then lets discuss what changes are appropriate. More inline. On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number of issues should be clarified before approval. Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wikipedia articles (subject to change, subject to attacks) as references, and I also believe that the current definitions (@11/21/13, US morning hours) are ambiguous. Actually the Wikipedia article does not include definitions for Left and Right, and speaks about 'house left' (equal to 'stage right') and 'house right' (equal to 'stage left'). If another specification in CLUE will use the terms defined here it is not clear which one is meant. This seems like a reasonable point to me. Is there a more stable reference we can use? If not, can we just define these terms in the document? [MB] I'm almost of a mind to just remove those definitions. The consensus was that the terms should be qualified when they are used and the framework does an excellent job of defining more precise terms that properly qualify "left" and "right" and differentiate from stage right, etc. as appropriate. We use "left" and "right" in one place in this requirements document and I think the use is general enough that we don't need a definition (in this document). The wikipedia reference has been in the document since day 1 as a WG document (it was added in -03 of the individual document). The discussions around "left"/"right" on the list were in the context of the definitions document and again, consensus was that the terms should be qualified (as they are in the framework), thus I don't think the current definitions serve any value. [/MB] [SB] I agree with Mary that these definitions can simply be removed. [/SB] [Duckworth, Mark] I agree too. 2. In REQMT-1d it is not clear what 'the extent of individual video captures' means 3. In REQMT-2d it is not clear what 'the extent of individual audio captures' means We have had our own concerns about this. I think we want to say *something* but its unclear to me exactly what. Perhaps we could focus on what we want to use this for, and explicitly leave details of what it is for the FW. [MB] Can you point to the threads of discussion where you feel this concern with this phrasing has been raised? There were certainly concerns raised about those requirements (i.e., 3D), but I'm not reading this as Dan's concern. My understanding is that the word "extent" is used in the context of video imagery from the perspective of the camera - i.e., the "angular extent" or something like that. I think we should replace the word "extent" with something more specific. Anyone have a suggestion? [SB] The intent of REQMT-1d was to say that CLUE needs to identify the area that each camera captured in the room - so it would be clear how views from different camera related to each other, and also if there were any gaps, etc. Identifying the scale of the view is related, but is captured concisely in requirement 6. Proper rendering in a multi-camera telepresence system requires this knowledge - today it is generally hard-wired into the room design. But that doesn't result in an interoperable experience, and it needs to be signaled if you want to get appropriate rendering between rooms with disparate designs. For audio [REQMT-2d], there is an analogous need to identify the area of coverage of a microphone. The need to correlate the audio and the video is related, but is captured separately in REQMT-3. The discussions on the list related to audio and video area of coverage were about whether the model in the framework was adequate. Personally I believe it is. But what really matters here is whether we are clearly stating the requirement, not the adequacy of the proposed specifications. One alternative term is "area of coverage", which is commonly used in surveillance applications to describe a similar concept. If people think that might be confused with radio coverage (e.g. an LTE coverage map) we could draft a definition and add it to section 3. [/SB] [Duckworth, Mark] I agree with Steve about the intent. I agree "area of coverage" is a better term than "extent" for this purpose. And, note these requirements were added based on discussion at IETF-82: http://www.ietf.org/proceedings/82/slides/clue-1.pdf [/MB] Thanks, Paul 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session (and what limitations) are expected from endpoints that do not support the telepresence extensions. I assume there are limitations, otherwise extensions would not be needed. [SB] The intent was to simply state that the solution must not prevent direct interoperability with SIP devices (either phone or videoconferencing) - without the need for a middlebox to convert signaling (as would be required with rtcweb for instance). The limitation is simply that telepresence extensions can't be used. I do not see a need to describe the limitations of existing SIP systems in this requirements document. Suggested text that makes the requirement more clear would be helpful. This is a bit tricky to word, since SIP itself has no requirement that says SIP endpoints must interoperate with each other w/o middleboxes to assist. And in fact they often don't. We could alternatively drop the requirement. [/SB] [Duckworth, Mark] I agree with Steve about the intent. How about something like "The solution must make it possible for devices that support CLUE to interoperate directly with SIP devices that do not support CLUE" ? 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations [SB]At this point I am not certain either. We might have meant that different use cases had different placements, number, and size of presentations. Or that existing telepresence systems handle presentations in different ways. It is not worded as a clear requirement, and it says "can", not "should" or "must". My recommendation is to delete that bullet. [/SB] [Duckworth, Mark] I think we meant this: - There can be multiple simultaneous presentation media streams - Presentation media streams can be spatially related to each other 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or extending the specifications for new functionality in the future? [SB] What is meant is extending the specifications for new functionality in the future. I suggest that we re-word to "New protocols developed for the solution MUST include extensibility mechanisms" [/SB] [Duckworth, Mark] Steve's suggestion is more clear. Minor issues: 1. If this is the first and basic document to be read by somebody who starts to browse through the CLUE specifications, it would be good to define or expand some place in the introduction what CLUE is. [SB] I am not sure if the CLUE WG has a recommended order for reading the various documents. Personally I would recommend that people start with the use cases. In any event, I think the document purpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as an orientation to CLUE specifications. [/SB] [Duckworth, Mark] I agree. 2. In the Introduction Section I see: These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is ambiguous. It would be good to mention (again) in section 5 that by what is meant by the 'solution' is the definition of the protocol, not the implementation. [SB] I agree. We should also use "specifications", since current plans call for more than one standards-track RFC [/SB] [Duckworth, Mark] I agree 3. I will defer to the Security Review to comment whether REQMT-18 is enough from a security point of view - especially as the information about media captures may include explicitly or implicitly details about equipment on each site, etc. To me it seems a little bit too vague. [SB] I don't see it as vague - it pretty clearly says that only the mechanism needs to be secure. I think you are saying that the security section might be incomplete. Current protocol designs do not include explicit details about equipment, and I see nothing in the requirements that suggest otherwise. Some requirements do require transport of information that can be used infer room dimensions (at least of the visible portion of the room) and the audio/video coverage within it. Can you identify threats that might use that information? Of course each specification includes its own Security Considerations. Obviously we will address any security review comments in this one. [/SB]. Regards, Dan ------=_NextPart_001_00D0_01CEF1C7.576B5180 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Mary,

 

What is the process here? 

The earlier comments imply that further changes may be needed and = possible.

Now, you say no changes are possible? 

What was the point of posting on the email = list?

Or, is it only comments from the anointed?

The anointed are free to use my comments how they like by the = way.  :)

 

I would also argue since the text is redundant, =

it is editorial change to remove to make the document = clearer.

 

Mike

 

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Thursday, December 05, 2013 2:09 PM
To: Michael = Hammer
Cc: Mark.Duckworth@polycom.com; = stephen.botzko@gmail.com; = draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; = clue@ietf.org
Subject: Re: [clue] Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 

HI = Michael,

 

Comments inline below = [MB].

 

Thanks,

Mary.

 

On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Requirement 15 is written in language that is more vague than the = other requirements.

I would argue that what it says is already covered by the other = requirements and could be removed with no = harm.

[MB] = You have a reasonable point, but I would suggest that leaving this = requirement also causes no harm. It's been in the document since the -00 = WG version.  It was added as REQMT-16 in the individual = -03.

Please keep in mind = that this document has completed IETF Last Call (we had consensus on = this document in the WG a while back), so there would have to an = extremely compelling reason and WG consensus to remove. =  

[/MB]

 

For example Reqts 2 and 4 seem to say that there will be multiple = devices involved in creating a = “presentation”.

And 5-9 seem to cover various interop issues with different numbers = and types of devices.

Also, presentation is not = defined.

[MB] Given that we have an entire use case dedication = to "presentation" I don't think the term needs to be defined = in this document. However, it would probably be good to add the = reference to the Presentation use case for REQMT-15 as we have done for = some others.   [/MB]

 

Mike

 

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, December 02, 2013 3:11 = PM
To: Stephen Botzko; Mary = Barnes


Cc: draft-ietf-clue-telepresence-requirements.all@tools.iet= f.org; clue@ietf.org
Subject: Re: [clue] = Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 <= /o:p>

Comments inline.

Mark Duckworth

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: Wednesday, November 27, 2013 5:28 = PM
To: Mary Barnes
Cc: draft-ietf-clue-telepresence-requirements.all@tools.iet= f.org; clue@ietf.org
Subject: Re: [clue] = Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 <= /o:p>

Dan - = thanks so much for reviewing this.

Comments are = in-line

 <= /o:p>

Stephen = Botzko

 <= /o:p>

On Thu, Nov = 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> = wrote:

On Thu, Nov = 21, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

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

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

More inline.



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

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

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

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

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

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

Major issues:

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

 <= /o:p>

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

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

[SB] I = agree with Mary that these definitions can simply be = removed.
[/SB]

[Duckworth, Mark] I agree too.

 

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

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

 <= /o:p>

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

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

[SB]

The intent = of REQMT-1d was to say that CLUE needs to identify the area that each = camera captured in the room - so it would be clear how views from = different camera related to each other, and also if there were any gaps, = etc.  Identifying the scale of the view is related, but is captured = concisely in requirement 6.  Proper rendering in a multi-camera = telepresence system requires this knowledge - today it is generally = hard-wired into the room design.  But that doesn't result in an = interoperable experience, and it needs to be signaled if you want to get = appropriate rendering between rooms with disparate = designs.

 <= /o:p>

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

 <= /o:p>

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

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

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.  I agree = “area of coverage” is a better term than = “extent” for this = purpose.

 <= /o:p>

 <= /o:p>

 

------=_NextPart_001_00D0_01CEF1C7.576B5180-- ------=_NextPart_000_00CF_01CEF1C7.576B5180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw NTE5MzYxMFowIwYJKoZIhvcNAQkEMRYEFO40NufInQjg6BQm7Vn9kcsovGoAMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAWq8/pY8bLsvMOoib61X/dGXh2qIdoHmJX+suA0lF jOp4mSqamXYQKGmWfyBiyN1oKm/x0ArEPRubIOBPyCmxVlSP3Zv1TUEparvH2IwzwxBV34cZCJjk s+DXU8FJ7zw4UWuGQMzvs5rVOIsY3G/gC3DTUOfovNinPRR9WSuCUj2S4coJsVZpXspUdfuHxhPn EEsOCbxY4nVyx0ZO1kIy3/6TH3GQRTCH5FHBZrenQbhC114y4Q0HSRrD6/gWn7ZZIymjkv7FqxUR d+WQzPYLNx8MSWcYvzzNT7LSJ5myJ5lK/qDvzg+7YN2RGEJtq4JlgLkvVBtsEwr+UUsuuTgNGgAA AAAAAA== ------=_NextPart_000_00CF_01CEF1C7.576B5180-- From mary.ietf.barnes@gmail.com Thu Dec 5 11:57:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDAA1AE04F for ; Thu, 5 Dec 2013 11:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjQHYbrXkM4t for ; Thu, 5 Dec 2013 11:57:23 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF7B1A802A for ; Thu, 5 Dec 2013 11:57:22 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id b13so14022154wgh.6 for ; Thu, 05 Dec 2013 11:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BsyoqH3trlMavzJnoRR2YqnO3R2wCamZ0kIa1QNrMss=; b=SYLM6dswORPdMVVv301kOLkxOlf0/xKk+9gNxtVSAmlCdDEHwvU4YYqKiQNN9zDRzC fUGSdWQpJLjpKYIgQRvzR3/zrBpocdlsVslk040mZ7iHzKC9sqHzkxkJNKOtFDL5tkJT nC9W9TGHxnHElOsmxmCJxUO4m8Fj98+k7bWh6fRA9L3qSGephaBrxF7qqgAkiQ2eryn0 U6UxE1P33QN8gu8OUbmLAwjoaNP/AsZnUcjRTk2tYW3yykELSyN52iSkfh/DlUdU8O1f q8FkLnHhNnAhzJ96gqpZlaL1mp6GbmdlRrJxgbeK1F6w9RQZ78P6zO7lTfWVJzM7R1qD rT5w== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr18952315wjt.64.1386273438663; Thu, 05 Dec 2013 11:57:18 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 5 Dec 2013 11:57:18 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF01ECB@sc9-ex2k10mb1.corp.yaanatech.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF01ECB@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 5 Dec 2013 13:57:18 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=047d7b3440dadf8e3404ecceef1a Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 19:57:29 -0000 --047d7b3440dadf8e3404ecceef1a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Responses below [MB]. Mary. On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer wrote: > Mary, > > > > What is the process here? > > The earlier comments imply that further changes may be needed and possibl= e. > [MB] The process is standard IETF document progression process: http://www.ietf.org/about/process-docs.html The WG completes WGLC (which was completed for this doc on Sunday, Sept. 29th). Then the document shepherd completes the write-up, reflecting that the WG believes the document is ready to progress - that was done on October 24th, 2013. The AD then reviews the write-up and decides whether the doc is ready for IETF Last Call. The IETF Last Call for this document started on October 30th and lasted 4 weeks due to overlap with the IETF meeting. Note, you can find all this information in the data tracker: http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/ They've added a lot of nice new features that you might find handy, including a link to Search the mailing list for any threads related to this document as well as the History of it's progression through the IETF process. This email thread and any suggested changes are based upon the Gen-ART review by Dan Romascanu during IETF Last Call. We brought the discussion to the WG mailing list since the changes are slightly more than editorial and we cannot make the changes without ensuring the WG is okay with them. Your comments arrived after IETF Last Call completed. Certainly, if someone finds something in a WG document that is terribly broken, they should be brought to the attention of the WG, but I don't think this comment fits in that category. [/MB] Now, you say no changes are possible? > [MB] What I'm saying is that this change does not seem necessary. It doesn't add clarity and the requirement as it is doesn't takeaway from the document. I haven't dug back through email threads to see why this requirement was added in the individual -03 - you might want to do that and you might find visiting the email archives related to the development of this document in the WG quite informative. Everyone in the WG had *plenty* of time to review this WG document over the past 2.5 years (the -03 version where this requirement first appeared was published in June of 2011. After a document leaves the WG, one should always be conservative with regards to changes. [/MB] > What was the point of posting on the email list? > [MB] See Above. [/MB] > Or, is it only comments from the anointed? > [MB] See above - the comments being considered are those that were sent during IETF Last Call. Your comments came after the completion of IETF Last Call. Typically comments that late in the cycle are not always incorporated unless there is a very compelling reason. I personally don't see that there is here. [/MB] > The anointed are free to use my comments how they like by the way. :) > [MB] And, that would the WG - if the WG decides that this change should be made after IETF Last Call - as noted, typically WGs want to be conservative about changes at this stage unless there is a really compelling reason. [/MB] > > > I would also argue since the text is redundant, > [MB] I don't at all see it as entirely redundant. It might be implying the same requirement, but it is also clearly spelling out requirements explicit to presentation, which are also related to requirements for other media. [/MB] > it is editorial change to remove to make the document clearer. > [MB] I actually believe it makes the document clearer by being very explicit as to the requirements associated with the presentation use case. [/MB] > > > Mike > > > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Thursday, December 05, 2013 2:09 PM > *To:* Michael Hammer > *Cc:* Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; > draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; > clue@ietf.org > > *Subject:* Re: [clue] Gen-ART review of > draft-ietf-clue-telepresence-requirements-06.txt > > > > HI Michael, > > > > Comments inline below [MB]. > > > > Thanks, > > Mary. > > > > On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer < > michael.hammer@yaanatech.com> wrote: > > Requirement 15 is written in language that is more vague than the other > requirements. > > I would argue that what it says is already covered by the other > requirements and could be removed with no harm. > > [MB] You have a reasonable point, but I would suggest that leaving this > requirement also causes no harm. It's been in the document since the -00 = WG > version. It was added as REQMT-16 in the individual -03. > > Please keep in mind that this document has completed IETF Last Call (we > had consensus on this document in the WG a while back), so there would ha= ve > to an extremely compelling reason and WG consensus to remove. > > [/MB] > > > > For example Reqts 2 and 4 seem to say that there will be multiple devices > involved in creating a =93presentation=94. > > And 5-9 seem to cover various interop issues with different numbers and > types of devices. > > Also, presentation is not defined. > > [MB] Given that we have an entire use case dedication to "presentation" I > don't think the term needs to be defined in this document. However, it > would probably be good to add the reference to the Presentation use case > for REQMT-15 as we have done for some others. [/MB] > > > > Mike > > > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mar= k > *Sent:* Monday, December 02, 2013 3:11 PM > *To:* Stephen Botzko; Mary Barnes > > > *Cc:* draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; > clue@ietf.org > *Subject:* Re: [clue] Gen-ART review of > draft-ietf-clue-telepresence-requirements-06.txt > > > > Comments inline. > > Mark Duckworth > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephen Botzko > *Sent:* Wednesday, November 27, 2013 5:28 PM > *To:* Mary Barnes > *Cc:* draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; > clue@ietf.org > *Subject:* Re: [clue] Gen-ART review of > draft-ietf-clue-telepresence-requirements-06.txt > > > > Dan - thanks so much for reviewing this. > > Comments are in-line > > > > Stephen Botzko > > > > On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes > wrote: > > On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat > wrote: > > Authors, > > What do you think of these comments? > If you aren't in agreement with all of them, then we should have a dialog > with Dan about them. > > If in agreement, then lets discuss what changes are appropriate. > > More inline. > > > > On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-clue-telepresence-requirements-06.txt > Reviewer: Dan Romascanu > Review Date: 11/21/13 > IETF LC End Date: 11/27/13 > IESG Telechat date: (if known) > > Summary: It's a good and well written document, almost ready, but a numbe= r > of issues should be clarified before approval. > > Major issues: > > 1. The definitions of Left and Right in Section 3 use an entry article in > Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of > Wikipedia articles (subject to change, subject to attacks) as references, > and I also believe that the current definitions (@11/21/13, US morning > hours) are ambiguous. Actually the Wikipedia article does not include > definitions for Left and Right, and speaks about 'house left' (equal to > 'stage right') and 'house right' (equal to 'stage left'). If another > specification in CLUE will use the terms defined here it is not clear whi= ch > one is meant. > > > > This seems like a reasonable point to me. Is there a more stable referenc= e > we can use? If not, can we just define these terms in the document? > > [MB] I'm almost of a mind to just remove those definitions. The consensu= s > was that the terms should be qualified when they are used and the framewo= rk > does an excellent job of defining more precise terms that properly qualif= y > "left" and "right" and differentiate from stage right, etc. as appropriat= e. > We use "left" and "right" in one place in this requirements document and= I > think the use is general enough that we don't need a definition (in this > document). The wikipedia reference has been in the document since day 1 > as a WG document (it was added in -03 of the individual document). The > discussions around "left"/"right" on the list were in the context of the > definitions document and again, consensus was that the terms should be > qualified (as they are in the framework), thus I don't think the current > definitions serve any value. [/MB] > > [SB] I agree with Mary that these definitions can simply be removed. > [/SB] > > *[Duckworth, Mark] I agree too.* > > > > 2. In REQMT-1d it is not clear what 'the extent of individual video > captures' means > > 3. In REQMT-2d it is not clear what 'the extent of individual audio > captures' means > > > > We have had our own concerns about this. I think we want to say > *something* but its unclear to me exactly what. Perhaps we could focus on > what we want to use this for, and explicitly leave details of what it is > for the FW. > > [MB] Can you point to the threads of discussion where you feel this > concern with this phrasing has been raised? There were certainly concer= ns > raised about those requirements (i.e., 3D), but I'm not reading this as > Dan's concern. My understanding is that the word "extent" is used in th= e > context of video imagery from the perspective of the camera - i.e., the > "angular extent" or something like that. I think we should replace the > word "extent" with something more specific. Anyone have a suggestion? > > [SB] > > The intent of REQMT-1d was to say that CLUE needs to identify the area > that each camera captured in the room - so it would be clear how views fr= om > different camera related to each other, and also if there were any gaps, > etc. Identifying the scale of the view is related, but is captured > concisely in requirement 6. Proper rendering in a multi-camera > telepresence system requires this knowledge - today it is generally > hard-wired into the room design. But that doesn't result in an > interoperable experience, and it needs to be signaled if you want to get > appropriate rendering between rooms with disparate designs. > > > > For audio [REQMT-2d], there is an analogous need to identify the area of > coverage of a microphone. The need to correlate the audio and the video = is > related, but is captured separately in REQMT-3. > > > > The discussions on the list related to audio and video area of coverage > were about whether the model in the framework was adequate. Personally I > believe it is. But what really matters here is whether we are clearly > stating the *requirement*, not the adequacy of the proposed > specifications. > > One alternative term is "area of coverage", which is commonly used in > surveillance applications to describe a similar concept. If people think > that might be confused with radio coverage (e.g. an LTE coverage map) we > could draft a definition and add it to section 3. > > [/SB] > > *[Duckworth, Mark] I agree with Steve about the intent. I agree =93area = of > coverage=94 is a better term than =93extent=94 for this purpose.* > > > > > > And, note these requirements were added based on discussion at IETF-82: > > http://www.ietf.org/proceedings/82/slides/clue-1.pdf > > > > [/MB] > > Thanks, > Paul > > > > 4. REQMT-10: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a > telepresence session with those that do. > > More clarity is needed to explain what level of participation in a sessio= n > (and what limitations) are expected from endpoints that do not support th= e > telepresence extensions. I assume there are limitations, otherwise > extensions would not be needed. > > [SB] The intent was to simply state that the solution must not prevent > direct interoperability with SIP devices (either phone or > videoconferencing) - without the need for a middlebox to convert signalin= g > (as would be required with rtcweb for instance). The limitation is simp= ly > that telepresence extensions can't be used. I do not see a need to > describe the limitations of existing SIP systems in this requirements > document. > > Suggested text that makes the requirement more clear would be helpful. > This is a bit tricky to word, since SIP itself has no requirement that sa= ys > SIP endpoints must interoperate with each other w/o middleboxes to assist= . > And in fact they often don't. We could alternatively drop the requiremen= t. > > [/SB] > > *[Duckworth, Mark] I agree with Steve about the intent. How about > something like =93The solution must make it possible for devices that sup= port > CLUE to interoperate directly with SIP devices that do not support CLUE= =94 ?* > > > 5. REQMT-15 (last bullet): I could not really figure out what is meant he= re > > * There can be variation in placement, number and size of > presentations > > [SB]At this point I am not certain either. We might have meant that > different use cases had different placements, number, and size of > presentations. Or that existing telepresence systems handle presentations > in different ways. > > It is not worded as a clear requirement, and it says "can", not "should" > or "must". My recommendation is to delete that bullet. > [/SB] > > *[Duckworth, Mark] I think we meant this:* > > * - There can be multiple simultaneous presentation media > streams* > > *- Presentation media streams can be spatially related to > each other* > > > > 6. REQMT-16: The solution MUST include extensibility mechanisms. > > What 'extensibility' is meant here? Extending the telepresence sessions, > or extending the specifications for new functionality in the future? > > [SB] What is meant is extending the specifications for new functionality > in the future. I suggest that we re-word to "New protocols developed for > the solution MUST include extensibility mechanisms" > [/SB] > > *[Duckworth, Mark] Steve=92s suggestion is more clear.* > > > > Minor issues: > > 1. If this is the first and basic document to be read by somebody who > starts to browse through the CLUE specifications, it would be good to > define or expand some place in the introduction what CLUE is. > > [SB] I am not sure if the CLUE WG has a recommended order for reading the > various documents. Personally I would recommend that people start with t= he > use cases. In any event, I think the document purpose is properly captur= ed > in the abstract - it is not intended to be an introduction to telepresenc= e > generally or as an orientation to CLUE specifications. > [/SB] > > *[Duckworth, Mark] I agree.* > > > > 2. In the Introduction Section I see: > > These > > requirements are for the specification, they are not requirements on > the telepresence systems implementing the solution/protocol that will > be specified. > > But then all requirements in section 5 start by 'The solution ...' which > is ambiguous. It would be good to mention (again) in section 5 that by wh= at > is meant by the 'solution' is the definition of the protocol, not the > implementation. > > [SB] I agree. We should also use "specifications", since current plans > call for more than one standards-track RFC > [/SB] > > *[Duckworth, Mark] I agree* > > > 3. I will defer to the Security Review to comment whether REQMT-18 is > enough from a security point of view - especially as the information abou= t > media captures may include explicitly or implicitly details about equipme= nt > on each site, etc. To me it seems a little bit too vague. > > [SB] I don't see it as vague - it pretty clearly says that only the > mechanism needs to be secure. I think you are saying that the security > section might be incomplete. > > Current protocol designs do not include explicit details about equipment, > and I see nothing in the requirements that suggest otherwise. Some > requirements do require transport of information that can be used infer > room dimensions (at least of the visible portion of the room) and the > audio/video coverage within it. Can you identify threats that might use > that information? > > Of course each specification includes its own Security Considerations. > Obviously we will address any security review comments in this one. > [/SB]. > > > Regards, > > Dan > > > > > --047d7b3440dadf8e3404ecceef1a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Responses below [MB].

Mary.

On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer <michael.hammer@yaanatech.com> wrote:
Mary,

=A0

What is the process here?=A0 <= /span>

The earlier comments imply that fu= rther changes may be needed and possible.

[MB] The process is standard IETF docum= ent progression process: =A0http://www.ietf.org/about/process-docs.html
The WG completes WGLC (which was completed for this doc on= Sunday, Sept. 29th). =A0Then the document shepherd completes the write-up,= reflecting that the WG believes the document is ready to progress - that w= as done on October 24th, 2013. =A0The AD then reviews the write-up and deci= des whether the doc is ready for IETF Last Call. =A0The IETF Last Call for = this document started on October 30th and =A0lasted 4 weeks due to overlap = with the IETF meeting. Note, you can find all this information in the data = tracker:=A0
They've added a lot of n= ice new features that you might find handy, including a link to Search the = mailing list for any threads related to this document as well as the Histor= y of it's progression through the IETF process.

This email thread and any suggested changes= are based upon the Gen-ART review by Dan Romascanu during IETF Last Call. = =A0We brought the discussion to the WG mailing list since the changes are s= lightly more than editorial and we cannot make the changes without ensuring= the WG is okay with them.

Your comments arrived after IETF Last= Call completed. =A0Certainly, if someone finds something in a WG document = that is terribly broken, they should be brought to the attention of the WG,= but I don't think this comment fits in that category. [/MB]

Now, you say no changes are possible?=A0

[MB] What I'm saying is that this c= hange does not seem necessary. =A0It doesn't add clarity and the requir= ement as it is doesn't takeaway from the document. =A0I haven't dug= back through email threads to see why this requirement was added in the in= dividual -03 - you might want to do that and you might find visiting the em= ail archives related to the development of this document in the WG quite in= formative. =A0 Everyone in the WG had *plenty* of time to review this WG do= cument over the past 2.5 years (the -03 version where this requirement firs= t appeared was published in June of 2011. =A0After a document leaves the WG= , one should always be conservative with regards to changes. [/MB]=A0

What was t= he point of posting on the email list?

[MB] See Above. [/MB]=A0

Or, is = it only comments from the anointed?

[MB] See above - the comments being con= sidered are those that were sent during IETF Last Call. Your comments came = after the completion of IETF Last Call. Typically comments that late in the= cycle are not always incorporated unless there is a very compelling reason= . =A0I personally don't see that there is here. [/MB]=A0

The anointe= d are free to use my comments how they like by the way.=A0 :)

[MB] And, that would the WG - if the WG= decides that this change should be made after IETF Last Call - as noted, = =A0typically WGs want to be conservative about changes at this stage unless= there is a really compelling reason. [/MB]=A0

=A0<= u>

I would also argue since the text is redunda= nt,

[MB] I don't at all s= ee it as entirely redundant. =A0It might be implying the same requirement, = but it is also clearly spelling out requirements explicit to presentation, = which are also related to requirements for other media. [/MB]
=A0

it is editorial change to remove to make the document clearer.=

[MB] I actually believe it makes the do= cument clearer by being very explicit as to the requirements associated wit= h the presentation use case. [/MB]=A0

= =A0

Mike

=A0

=A0

From= : M= ary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Thursday, December 05, 2013 2:09 PM
To: Michael Hamm= er
Cc: Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org


Subject: Re: [clue] Gen-ART review of dra= ft-ietf-clue-telepresence-requirements-06.txt

<= /p>

=A0

=

HI Michael,

=A0<= /p>

Comments inline below [MB].<= /u>

=A0

Thanks,

Mary.<= /u>

=A0<= u>

On Mon, Dec 2, 2013 at 2:34 PM, Micha= el Hammer <michael.hammer@yaanatech.com> wrote:

Requirement 15 is written in langu= age that is more vague than the other requirements.

I would argue that what it says is already c= overed by the other requirements and could be removed with no harm.<= u>

[MB] You have a reasonable point, b= ut I would suggest that leaving this requirement also causes no harm. It= 9;s been in the document since the -00 WG version. =A0It was added as REQMT= -16 in the individual -03.

Please keep in mind that this document ha= s completed IETF Last Call (we had consensus on this document in the WG a w= hile back), so there would have to an extremely compelling reason and WG co= nsensus to remove. =A0

[/MB]

=A0

For example Reqts 2 and 4 seem to say that there w= ill be multiple devices involved in creating a =93presentation=94.

And 5-9 seem to cover various interop issues= with different numbers and types of devices.

Also, presentation is not defined.

[MB] Given that we have an ent= ire use case dedication to "presentation" I don't think the t= erm needs to be defined in this document. However, it would probably be goo= d to add the reference to the Presentation use case for REQMT-15 as we have= done for some others. =A0 [/MB]

=A0

Mike

=A0

=A0

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark<= br> Sent: Monday, December 02, 2013 3:11 PM
To: Stephen Botzko= ; Mary Barnes


= Cc: draft-ietf-clue-telepresence-requirements= .all@tools.ietf.org; clue@ietf.org
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-r= equirements-06.txt

=A0

Com= ments inline.

Mark Duckworth

=A0

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen= Botzko
Sent: Wednesday, November 27, 2013 5:28 PM
To: Mary Barnes=
Cc: draft-ietf-clue-telepresence-requirem= ents.all@tools.ietf.org; clue@ietf.org
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-r= equirements-06.txt

=A0

Dan - thanks so much fo= r reviewing this.

Comments are in-line

= =A0

Stephen Botzko

=A0

On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wr= ote:

On Thu, Nov 21,= 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Authors,

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

If in agreement, then lets discuss what chan= ges are appropriate.

More inline.



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

<= p class=3D"MsoNormal">I am the assigned Gen-ART reviewer for this draft. Fo= r background on Gen-ART, please see the FAQ at

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

Please resolve these comments along with any other Last Call comments y= ou may receive.

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

Summary: It's a good and well wri= tten document, almost ready, but a number of issues should be clarified bef= ore approval.

Major issues:

1. The definitions of Left and Ri= ght in Section 3 use an entry article in Wikipedia ('Stage Directions&#= 39;). I am both uncomfortable with the usage of Wikipedia articles (subject= to change, subject to attacks) as references, and I also believe that the = current definitions (@11/21/13, US morning hours) are ambiguous. Actually t= he Wikipedia article does not include definitions for Left and Right, and s= peaks about 'house left' (equal to 'stage right') and '= house right' (equal to 'stage left'). If another specification = in CLUE will use the terms defined here it is not clear which one is meant.=

=A0

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

[MB] I'm almost of a min= d to just remove those definitions. =A0The consensus was that the terms sho= uld be qualified when they are used and the framework does an excellent job= of defining more precise terms that properly qualify "left" and = "right" and differentiate from stage right, etc. as appropriate. = =A0We use "left" and "right" in one place in this requi= rements document and I think the use is general enough that we don't ne= ed a definition (in this document). =A0 The wikipedia reference has been in= the document since day 1 as a WG document (it was added in -03 of the indi= vidual document). =A0 The discussions around "left"/"right&q= uot; on the list were in the context of the definitions document and again,= consensus was that the terms should be qualified (as they are in the frame= work), thus I don't think the current definitions serve any value.=A0[/= MB]=A0

[SB] I agree with Mary = that these definitions can simply be removed.
[/SB]

[Duckworth, Mark] I agree too.=

=A0

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

3. In REQMT-2d it is not cle= ar what 'the extent of individual audio captures' means

=A0

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

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

[SB]

The intent of REQMT-1d was to= say that CLUE needs to identify the area that each camera captured in the = room - so it would be clear how views from different camera related to each= other, and also if there were any gaps, etc.=A0 Identifying the scale of t= he view is related, but is captured concisely in requirement 6.=A0 Proper r= endering in a multi-camera telepresence system requires this knowledge - to= day it is generally hard-wired into the room design.=A0 But that doesn'= t result in an interoperable experience, and it needs to be signaled if you= want to get appropriate rendering between rooms with disparate designs.=

=A0

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

=A0

The discussions on the list rel= ated to audio and video area of coverage were about whether the model in th= e framework was adequate.=A0 Personally I believe it is.=A0 But what really= matters here is whether we are clearly stating the requirement, not= the adequacy of the proposed specifications.=A0

One alternative term is "area of cov= erage", which is commonly used in surveillance applications to describ= e a similar concept.=A0 If people think that might be confused with radio c= overage (e.g. an LTE coverage map) we could draft a definition and add it t= o section 3.

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.= =A0 I agree =93area of coverage=94 is a better term than =93extent=94 for t= his purpose.

=A0

=A0

And, note these requirements were added based on discussi= on at IETF-82:

= =A0

=A0[/MB]

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

=A0

4. REQMT-10: The solution MUST make it possible for en= dpoints without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support for telepresence = extensions to participate in a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0telepresence session with those that do.
=
More clarity is needed to explain what level of participation in a sess= ion (and what limitations) are expected from endpoints that do not support = the telepresence extensions. I assume there are limitations, otherwise exte= nsions would not be needed.

[SB] The intent was to simply state that = the solution must not prevent direct interoperability with SIP devices (eit= her phone or videoconferencing) - without the need for a middlebox to conve= rt signaling (as would be required with rtcweb for instance). =A0 The limit= ation is simply that telepresence extensions can't be used.=A0 I do not= see a need to describe the limitations of existing SIP systems in this req= uirements document.=A0

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

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.= =A0 How about something like =93The solution must make it possible for devi= ces that support CLUE to interoperate directly with SIP devices that do not= support CLUE=94 ?

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

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

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

It is not worded as a clear requirement, and it says "can", n= ot "should" or "must".=A0 My recommendation is to delet= e that bullet.
[/SB]

[Duckworth, Mark] I think we meant this:

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 =A0- There can be multiple simultaneous p= resentation media streams

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Presentat= ion media streams can be spatially related to each other<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0<= /i>

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

What 'extensibility' is meant here? Extending the telepresence = sessions, or extending the specifications for new functionality in the futu= re?

[SB] What is mea= nt is extending the specifications for new functionality in the future.=A0 = I suggest that we re-word to "New protocols developed for the solution= MUST include extensibility mechanisms"
[/SB]

[Duckworth, Ma= rk] Steve=92s suggestion is more clear.

<= br>
Minor issues:

1. If this is the first and basic document to be r= ead by somebody who starts to browse through the CLUE specifications, it wo= uld be good to define or expand some place in the introduction what CLUE is= .

[SB] I am not sure if the CLUE WG has a r= ecommended order for reading the various documents.=A0 Personally I would r= ecommend that people start with the use cases.=A0 In any event, I think the= document purpose is properly captured in the abstract - it is not intended= to be an introduction to telepresence generally or as an orientation to CL= UE specifications.
[/SB]

[Duckworth, Mar= k] I agree.

=A0

2= . In the Introduction Section I see:

=A0 These

= =A0 =A0 requirements are for the specification, they are not requirements o= n
=A0 =A0 the telepresence systems implementing the solution/protocol th= at will
=A0 =A0 be specified.

But then all requirements in section 5 start by 'The solution ...&#= 39; which is ambiguous. It would be good to mention (again) in section 5 th= at by what is meant by the 'solution' is the definition of the prot= ocol, not the implementation.

[SB] I agree.=A0 We should also use "= ;specifications", since current plans call for more than one standards= -track RFC
[/SB]

[Duckworth, Ma= rk] I agree


3. I will defer to the Security Review to commen= t whether REQMT-18 is enough from a security point of view - especially as = the information about media captures may include explicitly or implicitly d= etails about equipment on each site, etc. To me it seems a little bit too v= ague.

[SB] I don&#= 39;t see it as vague - it pretty clearly says that only the mechanism needs= to be secure.=A0 I think you are saying that the security section might be= incomplete.

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

Of course ea= ch specification includes its own Security Considerations. Obviously we wil= l address any security review comments in this one.
[/SB].=


Regards,

Dan

=A0

=A0

<= /div>

--047d7b3440dadf8e3404ecceef1a-- From michael.hammer@yaanatech.com Thu Dec 5 12:20:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46831AE1BE for ; Thu, 5 Dec 2013 12:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32hmXEPWeCVl for ; Thu, 5 Dec 2013 12:20:08 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1F1AE17F for ; Thu, 5 Dec 2013 12:19:49 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Thu, 5 Dec 2013 12:19:46 -0800 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: AQHO8e160rMmBBgWBU+3CE7PxRpYCJpF/WtwgACNPQD//3+dEA== Date: Thu, 5 Dec 2013 20:19:45 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF01FB4@sc9-ex2k10mb1.corp.yaanatech.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> <528E3706.1000102@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D6046A2945@CRPMBOXPRD07.polycom.com> <00C069FD01E0324C9FFCADF539701DB3BBF00349@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF01ECB@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.52] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00D7_01CEF1CD.6D234220" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" , "clue@ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:20:21 -0000 X-List-Received-Date: Thu, 05 Dec 2013 20:20:21 -0000 ------=_NextPart_000_00D7_01CEF1CD.6D234220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D8_01CEF1CD.6D234220" ------=_NextPart_001_00D8_01CEF1CD.6D234220 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit No problem. It was posted to the list. I provided my two cents. You can crank through the process as you see fit. Mike From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, December 05, 2013 2:57 PM To: Michael Hammer Cc: Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Responses below [MB]. Mary. On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer wrote: Mary, What is the process here? The earlier comments imply that further changes may be needed and possible. [MB] The process is standard IETF document progression process: http://www.ietf.org/about/process-docs.html The WG completes WGLC (which was completed for this doc on Sunday, Sept. 29th). Then the document shepherd completes the write-up, reflecting that the WG believes the document is ready to progress - that was done on October 24th, 2013. The AD then reviews the write-up and decides whether the doc is ready for IETF Last Call. The IETF Last Call for this document started on October 30th and lasted 4 weeks due to overlap with the IETF meeting. Note, you can find all this information in the data tracker: http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements/ They've added a lot of nice new features that you might find handy, including a link to Search the mailing list for any threads related to this document as well as the History of it's progression through the IETF process. This email thread and any suggested changes are based upon the Gen-ART review by Dan Romascanu during IETF Last Call. We brought the discussion to the WG mailing list since the changes are slightly more than editorial and we cannot make the changes without ensuring the WG is okay with them. Your comments arrived after IETF Last Call completed. Certainly, if someone finds something in a WG document that is terribly broken, they should be brought to the attention of the WG, but I don't think this comment fits in that category. [/MB] Now, you say no changes are possible? [MB] What I'm saying is that this change does not seem necessary. It doesn't add clarity and the requirement as it is doesn't takeaway from the document. I haven't dug back through email threads to see why this requirement was added in the individual -03 - you might want to do that and you might find visiting the email archives related to the development of this document in the WG quite informative. Everyone in the WG had *plenty* of time to review this WG document over the past 2.5 years (the -03 version where this requirement first appeared was published in June of 2011. After a document leaves the WG, one should always be conservative with regards to changes. [/MB] What was the point of posting on the email list? [MB] See Above. [/MB] Or, is it only comments from the anointed? [MB] See above - the comments being considered are those that were sent during IETF Last Call. Your comments came after the completion of IETF Last Call. Typically comments that late in the cycle are not always incorporated unless there is a very compelling reason. I personally don't see that there is here. [/MB] The anointed are free to use my comments how they like by the way. :) [MB] And, that would the WG - if the WG decides that this change should be made after IETF Last Call - as noted, typically WGs want to be conservative about changes at this stage unless there is a really compelling reason. [/MB] I would also argue since the text is redundant, [MB] I don't at all see it as entirely redundant. It might be implying the same requirement, but it is also clearly spelling out requirements explicit to presentation, which are also related to requirements for other media. [/MB] it is editorial change to remove to make the document clearer. [MB] I actually believe it makes the document clearer by being very explicit as to the requirements associated with the presentation use case. [/MB] Mike From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, December 05, 2013 2:09 PM To: Michael Hammer Cc: Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt HI Michael, Comments inline below [MB]. Thanks, Mary. On Mon, Dec 2, 2013 at 2:34 PM, Michael Hammer wrote: Requirement 15 is written in language that is more vague than the other requirements. I would argue that what it says is already covered by the other requirements and could be removed with no harm. [MB] You have a reasonable point, but I would suggest that leaving this requirement also causes no harm. It's been in the document since the -00 WG version. It was added as REQMT-16 in the individual -03. Please keep in mind that this document has completed IETF Last Call (we had consensus on this document in the WG a while back), so there would have to an extremely compelling reason and WG consensus to remove. [/MB] For example Reqts 2 and 4 seem to say that there will be multiple devices involved in creating a "presentation". And 5-9 seem to cover various interop issues with different numbers and types of devices. Also, presentation is not defined. [MB] Given that we have an entire use case dedication to "presentation" I don't think the term needs to be defined in this document. However, it would probably be good to add the reference to the Presentation use case for REQMT-15 as we have done for some others. [/MB] Mike From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, December 02, 2013 3:11 PM To: Stephen Botzko; Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Comments inline. Mark Duckworth From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephen Botzko Sent: Wednesday, November 27, 2013 5:28 PM To: Mary Barnes Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; clue@ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Dan - thanks so much for reviewing this. Comments are in-line Stephen Botzko On Thu, Nov 21, 2013 at 4:39 PM, Mary Barnes wrote: On Thu, Nov 21, 2013 at 10:38 AM, Paul Kyzivat wrote: Authors, What do you think of these comments? If you aren't in agreement with all of them, then we should have a dialog with Dan about them. If in agreement, then lets discuss what changes are appropriate. More inline. On 11/21/13 7:08 AM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number of issues should be clarified before approval. Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wikipedia articles (subject to change, subject to attacks) as references, and I also believe that the current definitions (@11/21/13, US morning hours) are ambiguous. Actually the Wikipedia article does not include definitions for Left and Right, and speaks about 'house left' (equal to 'stage right') and 'house right' (equal to 'stage left'). If another specification in CLUE will use the terms defined here it is not clear which one is meant. This seems like a reasonable point to me. Is there a more stable reference we can use? If not, can we just define these terms in the document? [MB] I'm almost of a mind to just remove those definitions. The consensus was that the terms should be qualified when they are used and the framework does an excellent job of defining more precise terms that properly qualify "left" and "right" and differentiate from stage right, etc. as appropriate. We use "left" and "right" in one place in this requirements document and I think the use is general enough that we don't need a definition (in this document). The wikipedia reference has been in the document since day 1 as a WG document (it was added in -03 of the individual document). The discussions around "left"/"right" on the list were in the context of the definitions document and again, consensus was that the terms should be qualified (as they are in the framework), thus I don't think the current definitions serve any value. [/MB] [SB] I agree with Mary that these definitions can simply be removed. [/SB] [Duckworth, Mark] I agree too. 2. In REQMT-1d it is not clear what 'the extent of individual video captures' means 3. In REQMT-2d it is not clear what 'the extent of individual audio captures' means We have had our own concerns about this. I think we want to say *something* but its unclear to me exactly what. Perhaps we could focus on what we want to use this for, and explicitly leave details of what it is for the FW. [MB] Can you point to the threads of discussion where you feel this concern with this phrasing has been raised? There were certainly concerns raised about those requirements (i.e., 3D), but I'm not reading this as Dan's concern. My understanding is that the word "extent" is used in the context of video imagery from the perspective of the camera - i.e., the "angular extent" or something like that. I think we should replace the word "extent" with something more specific. Anyone have a suggestion? [SB] The intent of REQMT-1d was to say that CLUE needs to identify the area that each camera captured in the room - so it would be clear how views from different camera related to each other, and also if there were any gaps, etc. Identifying the scale of the view is related, but is captured concisely in requirement 6. Proper rendering in a multi-camera telepresence system requires this knowledge - today it is generally hard-wired into the room design. But that doesn't result in an interoperable experience, and it needs to be signaled if you want to get appropriate rendering between rooms with disparate designs. For audio [REQMT-2d], there is an analogous need to identify the area of coverage of a microphone. The need to correlate the audio and the video is related, but is captured separately in REQMT-3. The discussions on the list related to audio and video area of coverage were about whether the model in the framework was adequate. Personally I believe it is. But what really matters here is whether we are clearly stating the requirement, not the adequacy of the proposed specifications. One alternative term is "area of coverage", which is commonly used in surveillance applications to describe a similar concept. If people think that might be confused with radio coverage (e.g. an LTE coverage map) we could draft a definition and add it to section 3. [/SB] [Duckworth, Mark] I agree with Steve about the intent. I agree "area of coverage" is a better term than "extent" for this purpose. And, note these requirements were added based on discussion at IETF-82: http://www.ietf.org/proceedings/82/slides/clue-1.pdf [/MB] Thanks, Paul 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session (and what limitations) are expected from endpoints that do not support the telepresence extensions. I assume there are limitations, otherwise extensions would not be needed. [SB] The intent was to simply state that the solution must not prevent direct interoperability with SIP devices (either phone or videoconferencing) - without the need for a middlebox to convert signaling (as would be required with rtcweb for instance). The limitation is simply that telepresence extensions can't be used. I do not see a need to describe the limitations of existing SIP systems in this requirements document. Suggested text that makes the requirement more clear would be helpful. This is a bit tricky to word, since SIP itself has no requirement that says SIP endpoints must interoperate with each other w/o middleboxes to assist. And in fact they often don't. We could alternatively drop the requirement. [/SB] [Duckworth, Mark] I agree with Steve about the intent. How about something like "The solution must make it possible for devices that support CLUE to interoperate directly with SIP devices that do not support CLUE" ? 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations [SB]At this point I am not certain either. We might have meant that different use cases had different placements, number, and size of presentations. Or that existing telepresence systems handle presentations in different ways. It is not worded as a clear requirement, and it says "can", not "should" or "must". My recommendation is to delete that bullet. [/SB] [Duckworth, Mark] I think we meant this: - There can be multiple simultaneous presentation media streams - Presentation media streams can be spatially related to each other 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or extending the specifications for new functionality in the future? [SB] What is meant is extending the specifications for new functionality in the future. I suggest that we re-word to "New protocols developed for the solution MUST include extensibility mechanisms" [/SB] [Duckworth, Mark] Steve's suggestion is more clear. Minor issues: 1. If this is the first and basic document to be read by somebody who starts to browse through the CLUE specifications, it would be good to define or expand some place in the introduction what CLUE is. [SB] I am not sure if the CLUE WG has a recommended order for reading the various documents. Personally I would recommend that people start with the use cases. In any event, I think the document purpose is properly captured in the abstract - it is not intended to be an introduction to telepresence generally or as an orientation to CLUE specifications. [/SB] [Duckworth, Mark] I agree. 2. In the Introduction Section I see: These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is ambiguous. It would be good to mention (again) in section 5 that by what is meant by the 'solution' is the definition of the protocol, not the implementation. [SB] I agree. We should also use "specifications", since current plans call for more than one standards-track RFC [/SB] [Duckworth, Mark] I agree 3. I will defer to the Security Review to comment whether REQMT-18 is enough from a security point of view - especially as the information about media captures may include explicitly or implicitly details about equipment on each site, etc. To me it seems a little bit too vague. [SB] I don't see it as vague - it pretty clearly says that only the mechanism needs to be secure. I think you are saying that the security section might be incomplete. Current protocol designs do not include explicit details about equipment, and I see nothing in the requirements that suggest otherwise. Some requirements do require transport of information that can be used infer room dimensions (at least of the visible portion of the room) and the audio/video coverage within it. Can you identify threats that might use that information? Of course each specification includes its own Security Considerations. Obviously we will address any security review comments in this one. [/SB]. Regards, Dan ------=_NextPart_001_00D8_01CEF1CD.6D234220 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

No problem.

It was posted to the list.

I provided my two cents.

You can crank through the process as you see = fit.

 

Mike

 

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Thursday, December 05, 2013 2:57 PM
To: Michael = Hammer
Cc: Mark.Duckworth@polycom.com; = stephen.botzko@gmail.com; = draft-ietf-clue-telepresence-requirements.all@tools.ietf.org; = clue@ietf.org
Subject: Re: [clue] Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 

Responses below [MB].

 

Mary.

On Thu, Dec 5, 2013 at 1:36 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Mary,

 

What is the process here? 

The earlier comments imply that further changes may be needed and = possible.

[MB] The process is standard IETF document progression = process:  http://www.ietf.org/= about/process-docs.html

 

The WG completes WGLC (which was completed for this = doc on Sunday, Sept. 29th).  Then the document shepherd completes = the write-up, reflecting that the WG believes the document is ready to = progress - that was done on October 24th, 2013.  The AD then = reviews the write-up and decides whether the doc is ready for IETF Last = Call.  The IETF Last Call for this document started on October 30th = and  lasted 4 weeks due to overlap with the IETF meeting. Note, you = can find all this information in the data = tracker: 

They've = added a lot of nice new features that you might find handy, including a = link to Search the mailing list for any threads related to this document = as well as the History of it's progression through the IETF = process.

 

This email thread and any suggested changes are based = upon the Gen-ART review by Dan Romascanu during IETF Last Call.  We = brought the discussion to the WG mailing list since the changes are = slightly more than editorial and we cannot make the changes without = ensuring the WG is okay with them.

 

Your comments arrived after IETF Last Call completed. =  Certainly, if someone finds something in a WG document that is = terribly broken, they should be brought to the attention of the WG, but = I don't think this comment fits in that category. = [/MB]

 

Now, you say no changes are = possible? 

[MB] What I'm saying is that this change does not seem = necessary.  It doesn't add clarity and the requirement as it is = doesn't takeaway from the document.  I haven't dug back through = email threads to see why this requirement was added in the individual = -03 - you might want to do that and you might find visiting the email = archives related to the development of this document in the WG quite = informative.   Everyone in the WG had *plenty* of time to review = this WG document over the past 2.5 years (the -03 version where this = requirement first appeared was published in June of 2011.  After a = document leaves the WG, one should always be conservative with regards = to changes. [/MB] 

What was the point of posting on the email = list?

[MB] See Above. = [/MB] 

Or, is it only comments from the = anointed?

[MB] See above - the comments being considered are = those that were sent during IETF Last Call. Your comments came after the = completion of IETF Last Call. Typically comments that late in the cycle = are not always incorporated unless there is a very compelling reason. =  I personally don't see that there is here. = [/MB] 

The anointed are free to use my comments how they like by the = way.  :)

[MB] And, that would the WG - if the WG decides that = this change should be made after IETF Last Call - as noted, =  typically WGs want to be conservative about changes at this stage = unless there is a really compelling reason. = [/MB] 

 

I would also argue since the text is = redundant,

[MB] I don't at all see it as entirely redundant. =  It might be implying the same requirement, but it is also clearly = spelling out requirements explicit to presentation, which are also = related to requirements for other media. = [/MB]

 

it is editorial change to remove to make the document = clearer.

[MB] I actually believe it makes the document clearer = by being very explicit as to the requirements associated with the = presentation use case. [/MB] 

 

Mike

 

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Thursday, December 05, 2013 2:09 PM
To: Michael = Hammer
Cc: Mark.Duckworth@polycom.com; stephen.botzko@gmail.com; draft-ietf-clue-telepresence-requirements.all@tools.iet= f.org; clue@ietf.org


Subject: Re: [clue] Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 <= /o:p>

HI = Michael,

 <= /o:p>

Comments = inline below [MB].

 <= /o:p>

Thanks,=

Mary.

 <= /p>

On Mon, Dec = 2, 2013 at 2:34 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Requirement 15 is written in language that is more vague than the = other requirements.

I would argue that what it says is already covered by the other = requirements and could be removed with no = harm.

[MB] You = have a reasonable point, but I would suggest that leaving this = requirement also causes no harm. It's been in the document since the -00 = WG version.  It was added as REQMT-16 in the individual = -03.

Please keep = in mind that this document has completed IETF Last Call (we had = consensus on this document in the WG a while back), so there would have = to an extremely compelling reason and WG consensus to remove. =  

[/MB]

 

For example Reqts 2 and 4 seem to say that there will be multiple = devices involved in creating a = “presentation”.

And 5-9 seem to cover various interop issues with different numbers = and types of devices.

Also, presentation is not = defined.

[MB] Given = that we have an entire use case dedication to "presentation" I = don't think the term needs to be defined in this document. However, it = would probably be good to add the reference to the Presentation use case = for REQMT-15 as we have done for some others.   = [/MB]

 

Mike

 

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, December 02, 2013 3:11 = PM
To: Stephen Botzko; Mary = Barnes


Cc: draft-ietf-clue-telepresence-requirements.all@tools.iet= f.org; clue@ietf.org
Subject: Re: [clue] = Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 <= /o:p>

Comments inline.

Mark Duckworth

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of = Stephen Botzko
Sent: Wednesday, November 27, 2013 5:28 = PM
To: Mary Barnes
Cc: draft-ietf-clue-telepresence-requirements.all@tools.iet= f.org; clue@ietf.org
Subject: Re: [clue] = Gen-ART review of = draft-ietf-clue-telepresence-requirements-06.txt

 <= /o:p>

Dan - = thanks so much for reviewing this.

Comments are = in-line

 <= /o:p>

Stephen = Botzko

 <= /o:p>

On Thu, Nov = 21, 2013 at 4:39 PM, Mary Barnes <mary.ietf.barnes@gmail.com> = wrote:

On Thu, Nov = 21, 2013 at 10:38 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

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

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

More inline.



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

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

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

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

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

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

Major issues:

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

 <= /o:p>

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

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

[SB] I = agree with Mary that these definitions can simply be = removed.
[/SB]

[Duckworth, Mark] I agree too.

 

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

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

 <= /o:p>

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

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

[SB]

The intent = of REQMT-1d was to say that CLUE needs to identify the area that each = camera captured in the room - so it would be clear how views from = different camera related to each other, and also if there were any gaps, = etc.  Identifying the scale of the view is related, but is captured = concisely in requirement 6.  Proper rendering in a multi-camera = telepresence system requires this knowledge - today it is generally = hard-wired into the room design.  But that doesn't result in an = interoperable experience, and it needs to be signaled if you want to get = appropriate rendering between rooms with disparate = designs.

 <= /o:p>

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

 <= /o:p>

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

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

[/SB]

[Duckworth, Mark] I agree with Steve about the intent.  I agree = “area of coverage” is a better term than = “extent” for this = purpose.

 <= /o:p>

 <= /o:p>

 <= /o:p>

 

------=_NextPart_001_00D8_01CEF1CD.6D234220-- ------=_NextPart_000_00D7_01CEF1CD.6D234220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIw NTIwMTk0NFowIwYJKoZIhvcNAQkEMRYEFJ1LARDTxcWMhDXyoVn+1Q//KXvQMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAUrxCjvYmhvJsYENMoJMQh2DHPJuRdhj3+G1seJx9 2I3pDU/YVnCEG6wAMjneUa6/c3vRjzL9F1eYuDmD5wNGNRypsxQFdjPhGnTBx+lXNtNYdryFsIIK nZmNKtoyhZGJ5VgXKC74xFTbiQFtbKI6Zn2+D+BWzVVmnXk4UHRSSMcRQqLhxmYHeB7kTh7j9vPn iFGSjeK57MY6XKc2ZU2CQUHEJib4pg2N85VdBvqPOxtIIEh20Qna9Vnjd1kqRa+5+dkcNND6HfAE CPlNRuKhTINVPfhKiqP3ZrTjMis0p9iDpFhrFGTutZoK/WS8xOARg8/42ZbJaNJmyzgdvQdQlAAA AAAAAA== ------=_NextPart_000_00D7_01CEF1CD.6D234220-- From internet-drafts@ietf.org Fri Dec 6 09:01:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE9C1AE30E; Fri, 6 Dec 2013 09:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82PW4boTSGDY; Fri, 6 Dec 2013 09:01:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E649E1ADFFB; Fri, 6 Dec 2013 09:01:24 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206170124.7807.1676.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 09:01:24 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-08.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:01:26 -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-08.txt Pages : 17 Date : 2013-12-06 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-08 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 Dec 6 10:05:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACAA1AE114 for ; Fri, 6 Dec 2013 10:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8o0ckmHd6hs for ; Fri, 6 Dec 2013 10:05:52 -0800 (PST) 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 62D511AE0FE for ; Fri, 6 Dec 2013 10:05:51 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so1038611wes.17 for ; Fri, 06 Dec 2013 10:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VfDd8jn9KRQa8Og5Um0U56wlGmV9biAymwaQGqB9Q9M=; b=rDEN3B9yvWinrnLOuAIEx7XXVXplp+AFb7jk1VPUbnq6QmuqDP1hHFBjEOGbM8x6qk TjEPMJcoRAQfJiM615Q/5bCHATM8bvays3c+nfUdxXGa7p3Qrvi7hBI7anGXS7hYyuvt K8+FDg72Jk56Z/Am+SnyD/uMt7WInBgO9WLB4Bs5QXZ3YLmw0V5gZuRyncF287TdyKdE MJl/NEdbjkw7FzekOHmoKDQfl5AqMepEbwMDwIJL7c5m7ZFQW1Nv4hSqXl9wkehJJBAe 2sKEQLLW+dcq7tNpvSCW6bAG2MKMqcP1FefUS2lielCXVe7fJ6PXy/8hASiBvkHYix8R WCOw== MIME-Version: 1.0 X-Received: by 10.194.9.41 with SMTP id w9mr4533092wja.82.1386353147130; Fri, 06 Dec 2013 10:05:47 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 6 Dec 2013 10:05:47 -0800 (PST) In-Reply-To: References: <1721875898.6613452.1386085979553.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> Date: Fri, 6 Dec 2013 12:05:47 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b5d23d2de3c3e04ece17eee Subject: Re: [clue] Doodle: Link for poll "CLUE Design team meeting - Roles" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:05:55 -0000 --047d7b5d23d2de3c3e04ece17eee Content-Type: text/plain; charset=ISO-8859-1 Hi all, It looks like December 17th remains optimal for the Role discussion based on the doodle poll - 2pm Central US is the best time. I'll send the Webex details for this meeting (only) shortly. Paul, you had a note about conflict with STOX, but STOX is at 10am Central (maybe you were looking a the UTC time). As far as the 10th, I would suggest we skip the meeting since we can't have the Data channel discussion and I'm not sure there is anything else queued up at this time. And, then we will have to defer the data channel discussion until January. Thanks, Mary. On Tue, Dec 3, 2013 at 9:56 AM, Mary Barnes wrote: > As mentioned on the design team call today, Christer (and I) won't be > available for the DT call next week. So, we will need to move the data > channel discussion to another week. As an alternative, we would like to > consider moving the Role discussion to next week (Dec. 10th). To ensure > we can get Christian on the call to lead the discussion, we would like to > switch the time. Note, that I've also included the 17th in the doodle in > case we can't get a quorum for the 10th. > > Please fill out the poll no later than Friday, December 6th at noon CST so > that we can get the topic/time confirmed > > Thanks, > Mary. > > > ---------- Forwarded message ---------- > From: Doodle > Date: Tue, Dec 3, 2013 at 9:52 AM > Subject: Doodle: Link for poll "CLUE Design team meeting - Roles" > To: Mary Barnes > > > You have initiated a poll "CLUE Design team meeting - Roles" at Doodle. > The link to your poll is: > > http://doodle.com/u3894ty7xkkcfbse > > Share this link with all those who should cast their votes. Do not forget > to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > --047d7b5d23d2de3c3e04ece17eee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

It looks like December 17th rem= ains optimal for the Role discussion based on the doodle poll - 2pm Central= US is the best time. =A0I'll send the Webex details for this meeting (= only) shortly.=A0

Paul, you had a note about conflict with STOX, but STOX= is at 10am Central (maybe you were looking a the UTC time).=A0

As far as the 10th, I would suggest we skip the mee= ting since we can't have the Data channel discussion and I'm not su= re there is anything else queued up at this time. =A0And, then we will have= to defer the data channel discussion until January.=A0

Thanks,
Mary.


On Tue, Dec 3, = 2013 at 9:56 AM, Mary Barnes <mary.ietf.barnes@gmail.com><= /span> wrote:
As mentioned on the design = team call today, Christer (and I) won't be available for the DT call ne= xt week. =A0So, we will need to move the data channel discussion to another= week. =A0As an alternative, we would like to consider moving the Role disc= ussion to next week (Dec. 10th). =A0 To ensure we can get Christian on the = call to lead the discussion, we would like to switch the time. =A0Note, tha= t I've also included the 17th in the doodle in case we can't get a = quorum for the 10th.=A0

Please fill out the poll no later than Friday, December 6th = at noon CST so that we can get the topic/time confirmed

Thanks,
Mary.=A0


---------- Forwarded message ----------
From: Doodle <mailer@doodle.com><= /span>
Date: Tue, Dec 3, 2013 at 9:52 AM
Subject: Doodle: Link for po= ll "CLUE Design team meeting - Roles"
To: Mary Barnes <mary.ietf.barnes@gmail.com>


You have initiated a= poll "CLUE Design team meeting - Roles" at Doodle. The link to y= our poll is:

http://doo= dle.com/u3894ty7xkkcfbse

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)


--047d7b5d23d2de3c3e04ece17eee-- From mary.ietf.barnes@gmail.com Fri Dec 6 10:23:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805231AD8F9 for ; Fri, 6 Dec 2013 10:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-ye1l0oNJpr for ; Fri, 6 Dec 2013 10:23:03 -0800 (PST) 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 50C131ADEB4 for ; Fri, 6 Dec 2013 10:23:03 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so1060306wes.17 for ; Fri, 06 Dec 2013 10:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tHGfzI2SEyH2bU5w2RAH2etE0FXTxFj6v470rPZC8zg=; b=v2g02Rx9nde/HWE5iPhJ4vcvlCJhuaA6JyzLOf6eZdTVL8m1zlO6O5359yW91udznP Qzq+S4ZmJ5AjNMivyLFcMODifd+i2Rp/2f53RNyqFMmerfUQXowGlGy6w1DifJl2QwZj HTd1k8t65hVCHWAAlpVkW9Kp2lcj1oBLcNgSQybWc6IQYN9J+sSvLy+M0iNmQPP9N335 UlsGfBVpB7yNdEWPQ4d1Gj1KITi3VT+mixhHJ9u9GH881f+vPEusEckTE8ydzXk3ZDxm IeDifgKn/GSf3AYrWlwbCvhYm2aN8sg1M71d991EQryVzBXtP3AfnfWs6XgKNs2tD8Mw U2pA== MIME-Version: 1.0 X-Received: by 10.180.93.8 with SMTP id cq8mr3755452wib.38.1386354178950; Fri, 06 Dec 2013 10:22:58 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 6 Dec 2013 10:22:58 -0800 (PST) In-Reply-To: <286886333.4082010.1384470802557.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <286886333.4082010.1384470802557.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Fri, 6 Dec 2013 12:22:58 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043892b15e8bf304ece1bc9e Subject: [clue] Fwd: Doodle: Link for poll "CLUE WG Virtual Interim" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:23:05 -0000 --f46d043892b15e8bf304ece1bc9e Content-Type: text/plain; charset=ISO-8859-1 As a reminder, we are still planning to hold a virtual interim meeting the end of January/early February. Please fill out the doodle poll ASAP so we can fix the date/time. Right now, Monday, January 27th, 8:30-10:30 Central US looks like one of the best options. Thanks, Mary. ---------- Forwarded message ---------- From: Doodle Date: Thu, Nov 14, 2013 at 5:13 PM Subject: Doodle: Link for poll "CLUE WG Virtual Interim" To: Mary Barnes You have initiated a poll "CLUE WG Virtual Interim" at Doodle. The link to your poll is: http://doodle.com/94tcraiw93sgnrf3 Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) --f46d043892b15e8bf304ece1bc9e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As a reminder, we are still planning to hold a virtual int= erim meeting the end of January/early February. =A0Please fill out the dood= le poll ASAP so we can fix the date/time. Right now, Monday, January 27th, = 8:30-10:30 Central US looks like one of the best options.

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: Doodle <= mailer@doodle.com>
Date: Thu, Nov 14, 2013 at 5:13 PM
Subject: Doodle: Link for poll "= CLUE WG Virtual Interim"
To: Mary Barnes <mary.ietf.barnes@gmail.com>


You h= ave initiated a poll "CLUE WG Virtual Interim" at Doodle. The lin= k to your poll is:

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

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)

--f46d043892b15e8bf304ece1bc9e-- From mary.ietf.barnes@gmail.com Fri Dec 6 10:34:37 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8501F1ADE84 for ; Fri, 6 Dec 2013 10:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN_hOwKEMxFn for ; Fri, 6 Dec 2013 10:34:34 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 134721AE079 for ; Fri, 6 Dec 2013 10:34:33 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so1049416wgh.32 for ; Fri, 06 Dec 2013 10:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mncSVDI7DWx4f9sU+sFUeYZsNc6TnKXJwYLuHle2chw=; b=GWF0DTpip2SVqT/mD87xmiZhMTBRe/vjnIX4dkRGYLu4bBt2dzlpLQzvjSvTNxWr5b t6iph43qMifNIR9MTNb13hWkydLJo6jYpOb+SHUzyyBFCcVbEDJgtYxZ8hqwZbGfIydH dlRElPn07RYd5qmrGWeL3kYF0UeGp9xFzAbIgrorLagzIaAJvB2AyjHmMJRGaIAEYQOe xpHYLL3sjF5eCGqxKZBxW+uJrUKgVMeUzHeEz/03NkqQJLgmEglzc8TI8PiYklm2iYsO Q1sLCHC652isNDV9GsFzzZy98OFIoV+oGQIhTTVZADPOsQsQ/36ViYfb2P2aYqSfUf/Y WDow== MIME-Version: 1.0 X-Received: by 10.181.11.197 with SMTP id ek5mr3678387wid.7.1386354869830; Fri, 06 Dec 2013 10:34:29 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 6 Dec 2013 10:34:29 -0800 (PST) Date: Fri, 6 Dec 2013 12:34:29 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04388e5b8c8b1604ece1e5e4 Subject: [clue] Webex Logistics for December 17th, 2013 Design Team meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:34:37 -0000 --f46d04388e5b8c8b1604ece1e5e4 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Clue Working Group Date: Fri, Dec 6, 2013 at 12:33 PM Subject: Meeting invitation: CLUE WG Design Team - Roles To: mary.ietf.barnes@gmail.com Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Design Team - Roles Date: Tuesday, December 17, 2013 Time: 2:00 pm, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 644 105 875 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=256851862&UID=1716555617&PW=NZTZlMmJjYTQz&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=256851862&UID=1716555617&PW=NZTZlMmJjYTQz&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:644 105 875 ------------------------------------------------------- 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=256851862&UID=1716555617&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAhOOiM5E8rHi0TNnM85-pMawy73MwJmruoSZKsGxPHUn&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:+16504793208x644105875# 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. --f46d04388e5b8c8b1604ece1e5e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.co= m>
Date: Fri, Dec 6, 2013 at 12:33 PM
Subject: Meeting invitation: CLUE WG = Design Team - Roles
To: ma= ry.ietf.barnes@gmail.com



Hello ,

Clue Working Group invites you to attend this online mee= ting.

Topic: CLUE WG Design Team - Roles
Date: Tuesday, Dece= mber 17, 2013
Time: 2:00 pm, Central Standard Time (Chicago, GMT-06:00= )
Meeting Number: 644 105 875
Meeting Password: 1234


---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to htt= ps://ietf.webex.com/ietf/j.php?ED=3D256851862&UID=3D1716555617&PW= =3DNZTZlMmJjYTQz&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=3D256851862&UID=3D1716555617&PW=3DNZTZlMm= JjYTQz&ORT=3DMiM3

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

Access code:644 105 875

-----------------------------------= --------------------
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=3D256851862&UID=3D1716555617&ICS= =3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAhOOiM5E8rHi0TNnM85-p= Mawy73MwJmruoSZKsGxPHUn&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:+16504793208x644105875#

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.

--f46d04388e5b8c8b1604ece1e5e4-- From mary.ietf.barnes@gmail.com Fri Dec 6 13:47:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FC91AD8E1 for ; Fri, 6 Dec 2013 13:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpVjq_mfbbJG for ; Fri, 6 Dec 2013 13:47:00 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id C75DE1ACCDE for ; Fri, 6 Dec 2013 13:46:59 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y10so1349502wgg.4 for ; Fri, 06 Dec 2013 13:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x42a27ozEu3vQYFTHeY2880sl8mO1RJ29DyxZM1s0M8=; b=jrOu+qTDAvaFNQelCN6ZtFNVoOYcPT5DyhKxjjZF3V7xe1gEV4o6lkGvqzzPULsgvn vyewshWXuJYTDEQF35fAdhlkS1NaVRhwz3cV7gqVzqEXaiGG0o9x4oo+HORXBKziMnRy akdxKxaDhvtJfuZeGPTJYpFIZjL1qMdxPtNMHeb1b4ZEw52gBYpiz8SeebiQjLXUfUke pWEqxc6p4hUTWu6MwxPDilVDC+FbLaXIZT3rBfKHV/qhi3QMfrizXcdT/R+PlYTiGi7b LFV/PMN1cHK/CTZOtyWSffFeDiTr463TzCJqsllYx6+yXYTqd6ce+LhoUbtRl79XAymE KbtA== MIME-Version: 1.0 X-Received: by 10.194.2.108 with SMTP id 12mr5211336wjt.64.1386366415528; Fri, 06 Dec 2013 13:46:55 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 6 Dec 2013 13:46:55 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> Date: Fri, 6 Dec 2013 15:46:55 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b3440dab9e65804ece49539 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:47:03 -0000 --047d7b3440dab9e65804ece49539 Content-Type: text/plain; charset=ISO-8859-1 CLUE WG, Below, I've summarized changes based on Dan's comments. I've tried to incorporate from the various threads of discussion and in some cases I've proposed slightly different text. I plan to submit an update with these changes early next week, so please comment ASAP if you see any issues. Thanks, Mary. On Thu, Nov 21, 2013 at 9:08 AM, Romascanu, Dan (Dan) wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments you > may receive. > > Document: draft-ietf-clue-telepresence-requirements-06.txt > Reviewer: Dan Romascanu > Review Date: 11/21/13 > IETF LC End Date: 11/27/13 > IESG Telechat date: (if known) > > Summary: It's a good and well written document, almost ready, but a number > of issues should be clarified before approval. > > Major issues: > > 1. The definitions of Left and Right in Section 3 use an entry article in > Wikipedia ('Stage Directions'). I am both uncomfortable with the usage of > Wikipedia articles (subject to change, subject to attacks) as references, > and I also believe that the current definitions (@11/21/13, US morning > hours) are ambiguous. Actually the Wikipedia article does not include > definitions for Left and Right, and speaks about 'house left' (equal to > 'stage right') and 'house right' (equal to 'stage left'). If another > specification in CLUE will use the terms defined here it is not clear which > one is meant. > [MB] These definitions will be deleted, as they're not needed in the context of the requirements and the use of the terms in the other CLUE WG documents is within a context specific enough that the terms don't need to be redefined from their normal English language usage. [/MB] > > 2. In REQMT-1d it is not clear what 'the extent of individual video > captures' means > > 3. In REQMT-2d it is not clear what 'the extent of individual audio > captures' means > [MB] The proposal for these two issues is to change "extent" to "area of coverage". [/MB] > > 4. REQMT-10: The solution MUST make it possible for endpoints without > support for telepresence extensions to participate in a > telepresence session with those that do. > > More clarity is needed to explain what level of participation in a session > (and what limitations) are expected from endpoints that do not support the > telepresence extensions. I assume there are limitations, otherwise > extensions would not be needed. > [MB] As mentioned on the mailing list we don't believe it's necessary to define all the limits in the requirements. Basically, we're trying to say that an existing SIP endpoint that supports a single audio and video stream should be able to establish a basic audio & video session with a CLUE endpoint. This is no different than existing video systems, for example, that still allow a participant to join in audio only mode. It's also probably best to word the requirement from the perspective of the endpoint that supports telepresence extensions (since that's who these requirements apply to). Note, that the WG plans to address (and already has some text in solution documents) various scenarios involving "non-CLUE enabled" endpoints. We also have an issue in the tracker. I think rewording this requirement something like the following should be sufficient: REQMT-10: The solution MUST ensure that endpoints that support telepresence extensions can establish a session with a SIP endpoint that does not support the telepresence extensions. For example, in the case of a SIP endpoint that supports a single audio and a single video stream, an endpoint that supports the telepresence extensions would setup a session with a single audio and single video stream using existing SIP and SDP protocol mechanisms. [/MB] > > 5. REQMT-15 (last bullet): I could not really figure out what is meant here > > * There can be variation in placement, number and size of > presentations > [MB] I think this whole requirement can be slightly reworded something like the following, with that last bullet being made more specific and normative. I think this wording is better as each of these bullets could now be read as a separate requirement: REQMT-15: The solution MUST provide mechanisms to support the following: * Presentations with different media sources * Presentations for which the media streams are visible to all endpoints * Multiple, simultaneous presentation media streams, including presentation media streams that are spatially related to each other. Use case is presentation. [/MB] > 6. REQMT-16: The solution MUST include extensibility mechanisms. > > What 'extensibility' is meant here? Extending the telepresence sessions, > or extending the specifications for new functionality in the future? > [MB] Suggestion is to reword this as: REQMT-16: The specification of any new protocols for the solution MUST provide extensibility mechanisms. [/MB] > > > Minor issues: > > 1. If this is the first and basic document to be read by somebody who > starts to browse through the CLUE specifications, it would be good to > define or expand some place in the introduction what CLUE is. > [MB] The proposal is to expand the use of CLUE in the abstract as follows: OLD: This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. NEW This memo discusses the requirements for specifications, that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). [/MB] > > 2. In the Introduction Section I see: > > > These > requirements are for the specification, they are not requirements on > the telepresence systems implementing the solution/protocol that will > be specified. > > But then all requirements in section 5 start by 'The solution ...' which > is ambiguous. It would be good to mention (again) in section 5 that by what > is meant by the 'solution' is the definition of the protocol, not the > implementation. > [MB] Agreed. We'll add the following sentence right before the last sentence in paragraph 1 in section 5. "Note, the term "solution" is used in these requirements to mean the protocol specifications, including extensions to existing protocols as well as any new protocols, developed to support the use cases." [/MB] > > 3. I will defer to the Security Review to comment whether REQMT-18 is > enough from a security point of view - especially as the information about > media captures may include explicitly or implicitly details about equipment > on each site, etc. To me it seems a little bit too vague. > > Regards, > > Dan > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b3440dab9e65804ece49539 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
CLUE WG,=A0

Below, I've summarized changes based on Dan's comments. =A0I'= ve tried to incorporate from the various threads of discussion and in some = cases I've proposed slightly different text. =A0I plan to submit an upd= ate with these changes early next week, so please comment ASAP if you see a= ny issues.

Thanks,
Mary.=A0


On Thu, Nov 21, 2013 at 9:08 AM, Rom= ascanu, Dan (Dan) <dromasca@avaya.com> wrote:
I am the assigned Gen-ART reviewer for this draft. For bac= kground on Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

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

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

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

Major issues:

1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usa= ge of Wikipedia articles (subject to change, subject to attacks) as referen= ces, and I also believe that the current definitions (@11/21/13, US morning= hours) are ambiguous. Actually the Wikipedia article does not include defi= nitions for Left and Right, and speaks about 'house left' (equal to= 'stage right') and 'house right' (equal to 'stage left= '). If another specification in CLUE will use the terms defined here it= is not clear which one is meant.
[MB] These definitions will be deleted, as they're no= t needed in the context of the requirements and the use of the terms in the= other CLUE WG documents is within a context specific enough that the terms= don't need to be redefined from their normal English language usage. [= /MB]

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

3. In REQMT-2d it is not clear what 'the extent of individual audio cap= tures' means
[MB] The proposal for these two issue= s is to change "extent" to "area of coverage". [/MB]
=A0

4. REQMT-10: The solution MUST make it possible for endpoints without
=A0 =A0 =A0 =A0 =A0 =A0 =A0 support for telepresence extensions to particip= ate in a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 telepresence session with those that do.

More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed.
[MB] As mentioned on the mailing list we don't believ= e it's necessary to define all the limits in the requirements. =A0Basic= ally, we're trying to say that an existing SIP endpoint that supports a= single audio and video stream should be able to establish a basic audio &a= mp; video session with a CLUE endpoint. =A0This is no different than existi= ng video systems, for example, that still allow a participant to join in au= dio only mode. =A0It's also probably best to word the requirement from = the perspective of the endpoint that supports telepresence extensions (sinc= e that's who these requirements apply to). Note, that the WG plans to a= ddress (and already has some text in solution documents) various scenarios = involving "non-CLUE enabled" endpoints. =A0We also have an issue = in the tracker.=A0

I think rewording this requirement something like the f= ollowing should be sufficient:

REQMT-10: =A0 The solution= MUST ensure that endpoints that support telepresence=A0
extensio= ns can establish a session with a SIP endpoint that does not support the te= lepresence extensions. =A0For example, in the case of a SIP endpoint that s= upports a single audio and a single video stream, an endpoint that supports= the telepresence extensions would setup a session with a single audio and = single video stream using existing SIP and SDP protocol mechanisms. =A0

[/MB]

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

* =A0There can be variation in placement, number and size of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0presentations
[MB] = I think this whole requirement can be slightly reworded something like the = following, with that last bullet being made more specific and normative. = =A0I think this wording is better as each of these bullets could now be rea= d as a separate requirement:

REQMT-15:  The solution MUST provide mechanisms to support the following:=
  
          =
    *  Presentations with different media sources

              *  Presentations for which the media streams are visible to a=
ll endpoints
              *  Multiple, simultaneous presentation media streams, inc=
luding presentation media streams that are spatially related to each other.=

   Use case is pre=
sentation.              

[/MB]

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

What 'extensibility' is meant here? Extending the telepresence sess= ions, or extending the specifications for new functionality in the future?<= br>
[MB] Suggestion is to reword this as:

REQMT-16: =A0The specification of any new protocols for= the solution MUST provide extensibility mechanisms.=A0

[/MB]


Minor issues:

1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is.
[MB] The proposal is to expand the use of CLUE in the abstract as follows:<= /div>

OLD:
=A0 =A0This memo discusses the requirements for specifications that enable
   telepresence interoperabilit=
y, by describing the relationship between
   multiple RTP streams. 
NEW
   This memo discusses the requirements for specifications, that enable
   telepresence interoperabilit=
y by describing behaviors and protocols for=A0=
Controlling   Multiple Streams for Tel=
epresence (CLUE). =A0

[/MB]

2. In the Introduction Section I see:

> =A0These
=A0 =A0requirements are for the specification, they are not requirements on=
=A0 =A0the telepresence systems implementing the solution/protocol that wil= l
=A0 =A0be specified.

But then all requirements in section 5 start by 'The solution ...' = which is ambiguous. It would be good to mention (again) in section 5 that b= y what is meant by the 'solution' is the definition of the protocol= , not the implementation.
[MB] Agreed. =A0We'll add the following sentence righ= t before the last sentence in paragraph 1 in section 5.
=A0
=
"Note, the term "solution" is used in these requirement= s to mean the protocol specifications, including extensions to existing pro= tocols as well as any new protocols, =A0developed to support the use cases.= "

[/MB]=A0

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

Regards,

Dan

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

--047d7b3440dab9e65804ece49539-- From dromasca@avaya.com Sun Dec 8 04:17:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5A1ADF6B for ; Sun, 8 Dec 2013 04:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNo3oIB2rAlO for ; Sun, 8 Dec 2013 04:16:58 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 57DF81ADF47 for ; Sun, 8 Dec 2013 04:16:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4GALRipFLGmAcV/2dsb2JhbABZgkMjIThTsD+IUYEXFnSCJQEBAQECAQEBAQ8bQQQCBQULAgEIDQQDAQEBCxYHBycLFAkIAgQBDQUIEweFe4FfBgEMpl6ZOBeNIYE+IA0EBgGDIIETA5lEhTyLJ4MpgWhC X-IronPort-AV: E=Sophos;i="4.93,851,1378872000"; d="scan'208,217";a="40392380" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Dec 2013 07:16:51 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 08 Dec 2013 07:09:24 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Sun, 8 Dec 2013 13:16:50 +0100 From: "Romascanu, Dan (Dan)" To: Mary Barnes , CLUE Thread-Topic: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt Thread-Index: AQHO8syua5HTpe6g2Ua089zRYSQzy5pKOONA Date: Sun, 8 Dec 2013 12:16:50 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129DB825@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA12943EA9@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA129DB825AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "draft-ietf-clue-telepresence-requirements.all@tools.ietf.org" Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirements-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 12:17:03 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA129DB825AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW - with the proposed changes below I am a happy Gen-ART reviewer and co= nsider all my comments addressed. Thanks and Regards, Dan From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, December 06, 2013 11:47 PM To: CLUE Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-requirem= ents-06.txt CLUE WG, Below, I've summarized changes based on Dan's comments. I've tried to inco= rporate from the various threads of discussion and in some cases I've propo= sed slightly different text. I plan to submit an update with these changes= early next week, so please comment ASAP if you see any issues. Thanks, Mary. On Thu, Nov 21, 2013 at 9:08 AM, Romascanu, Dan (Dan) > wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-clue-telepresence-requirements-06.txt Reviewer: Dan Romascanu Review Date: 11/21/13 IETF LC End Date: 11/27/13 IESG Telechat date: (if known) Summary: It's a good and well written document, almost ready, but a number = of issues should be clarified before approval. Major issues: 1. The definitions of Left and Right in Section 3 use an entry article in W= ikipedia ('Stage Directions'). I am both uncomfortable with the usage of Wi= kipedia articles (subject to change, subject to attacks) as references, and= I also believe that the current definitions (@11/21/13, US morning hours) = are ambiguous. Actually the Wikipedia article does not include definitions = for Left and Right, and speaks about 'house left' (equal to 'stage right') = and 'house right' (equal to 'stage left'). If another specification in CLUE= will use the terms defined here it is not clear which one is meant. [MB] These definitions will be deleted, as they're not needed in the contex= t of the requirements and the use of the terms in the other CLUE WG documen= ts is within a context specific enough that the terms don't need to be rede= fined from their normal English language usage. [/MB] 2. In REQMT-1d it is not clear what 'the extent of individual video capture= s' means 3. In REQMT-2d it is not clear what 'the extent of individual audio capture= s' means [MB] The proposal for these two issues is to change "extent" to "area of co= verage". [/MB] 4. REQMT-10: The solution MUST make it possible for endpoints without support for telepresence extensions to participate in a telepresence session with those that do. More clarity is needed to explain what level of participation in a session = (and what limitations) are expected from endpoints that do not support the = telepresence extensions. I assume there are limitations, otherwise extensio= ns would not be needed. [MB] As mentioned on the mailing list we don't believe it's necessary to de= fine all the limits in the requirements. Basically, we're trying to say th= at an existing SIP endpoint that supports a single audio and video stream s= hould be able to establish a basic audio & video session with a CLUE endpoi= nt. This is no different than existing video systems, for example, that st= ill allow a participant to join in audio only mode. It's also probably bes= t to word the requirement from the perspective of the endpoint that support= s telepresence extensions (since that's who these requirements apply to). N= ote, that the WG plans to address (and already has some text in solution do= cuments) various scenarios involving "non-CLUE enabled" endpoints. We also= have an issue in the tracker. I think rewording this requirement something like the following should be s= ufficient: REQMT-10: The solution MUST ensure that endpoints that support telepresen= ce extensions can establish a session with a SIP endpoint that does not suppor= t the telepresence extensions. For example, in the case of a SIP endpoint = that supports a single audio and a single video stream, an endpoint that su= pports the telepresence extensions would setup a session with a single audi= o and single video stream using existing SIP and SDP protocol mechanisms. [/MB] 5. REQMT-15 (last bullet): I could not really figure out what is meant here * There can be variation in placement, number and size of presentations [MB] I think this whole requirement can be slightly reworded something like= the following, with that last bullet being made more specific and normativ= e. I think this wording is better as each of these bullets could now be re= ad as a separate requirement: REQMT-15: The solution MUST provide mechanisms to support the following: * Presentations with different media sources * Presentations for which the media streams are visible to a= ll endpoints * Multiple, simultaneous presentation media streams, includi= ng presentation media streams that are spatially related to each other. Use case is presentation. [/MB] 6. REQMT-16: The solution MUST include extensibility mechanisms. What 'extensibility' is meant here? Extending the telepresence sessions, or= extending the specifications for new functionality in the future? [MB] Suggestion is to reword this as: REQMT-16: The specification of any new protocols for the solution MUST pro= vide extensibility mechanisms. [/MB] Minor issues: 1. If this is the first and basic document to be read by somebody who start= s to browse through the CLUE specifications, it would be good to define or = expand some place in the introduction what CLUE is. [MB] The proposal is to expand the use of CLUE in the abstract as follows: OLD: This memo discusses the requirements for specifications that enable telepresence interoperability, by describing the relationship between multiple RTP streams. NEW This memo discusses the requirements for specifications, that enable telepresence interoperability by describing behaviors and protocols for = Controlling Multiple Streams for Telepresence (CLUE). [/MB] 2. In the Introduction Section I see: > These requirements are for the specification, they are not requirements on the telepresence systems implementing the solution/protocol that will be specified. But then all requirements in section 5 start by 'The solution ...' which is= ambiguous. It would be good to mention (again) in section 5 that by what i= s meant by the 'solution' is the definition of the protocol, not the implem= entation. [MB] Agreed. We'll add the following sentence right before the last senten= ce in paragraph 1 in section 5. "Note, the term "solution" is used in these requirements to mean the protoc= ol specifications, including extensions to existing protocols as well as an= y new protocols, developed to support the use cases." [/MB] 3. I will defer to the Security Review to comment whether REQMT-18 is enoug= h from a security point of view - especially as the information about media= captures may include explicitly or implicitly details about equipment on e= ach site, etc. To me it seems a little bit too vague. Regards, Dan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_9904FB1B0159DA42B0B887B7FA8119CA129DB825AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW – with the pro= posed changes below I am a happy Gen-ART reviewer and consider all my comme= nts addressed.

 <= /p>

Thanks and Regards,<= /o:p>

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: clue [ma= ilto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Friday, December 06, 2013 11:47 PM
To: CLUE
Cc: draft-ietf-clue-telepresence-requirements.all@tools.ietf.org
Subject: Re: [clue] Gen-ART review of draft-ietf-clue-telepresence-r= equirements-06.txt

 

CLUE WG, 

 

Below, I've summarized changes based on Dan's commen= ts.  I've tried to incorporate from the various threads of discussion = and in some cases I've proposed slightly different text.  I plan to su= bmit an update with these changes early next week, so please comment ASAP if you see any issues.

 

Thanks,

Mary. 

 

On Thu, Nov 21, 2013 at 9:08 AM, Romascanu, Dan (Dan= ) <dromasca@avay= a.com> wrote:

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq&= gt;.

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

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

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

Major issues:

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

[MB] These definitions will be deleted, as they're n= ot needed in the context of the requirements and the use of the terms in th= e other CLUE WG documents is within a context specific enough that the term= s don't need to be redefined from their normal English language usage. [/MB]


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

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

[MB] The proposal for these two issues is to change = "extent" to "area of coverage". [/MB]

 


4. REQMT-10: The solution MUST make it possible for endpoints without
              support for telepresence e= xtensions to participate in a
              telepresence session with = those that do.

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

[MB] As mentioned on the mailing list we don't belie= ve it's necessary to define all the limits in the requirements.  Basic= ally, we're trying to say that an existing SIP endpoint that supports a sin= gle audio and video stream should be able to establish a basic audio & video session with a CLUE endpoint.  = ;This is no different than existing video systems, for example, that still = allow a participant to join in audio only mode.  It's also probably be= st to word the requirement from the perspective of the endpoint that supports telepresence extensions (since that's who th= ese requirements apply to). Note, that the WG plans to address (and already= has some text in solution documents) various scenarios involving "non= -CLUE enabled" endpoints.  We also have an issue in the tracker. 

 

I think rewording thi= s requirement something like the following should be sufficient:=

REQMT-10:   The solution MUST ensure that endpo= ints that support telepresence 

extensions can establish a session with a SIP endpoi= nt that does not support the telepresence extensions.  For example, in= the case of a SIP endpoint that supports a single audio and a single video= stream, an endpoint that supports the telepresence extensions would setup a session with a single audio and sing= le video stream using existing SIP and SDP protocol mechanisms.  =

 

[/MB]


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

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

[MB] I think this whole requirement can be slightly = reworded something like the following, with that last bullet being made mor= e specific and normative.  I think this wording is better as each of t= hese bullets could now be read as a separate requirement:

 

REQMT-15:  Th=
e solution MUST provide mechanisms to support the following:  
   =
           *  P=
resentations with different media sources
 
            &nb=
sp; *  Presentations for which the media streams are visible to a=
ll endpoints
   =
           *  Multip=
le, simultaneous presentation media streams, including presentation media s=
treams that are spatially related to each other.
   Use c=
ase is presentation.          =
    
 <=
/pre>

 <=
/pre>

[=
/MB]


6. REQMT-16:  The solution MUST include extensibility mechanisms.

What 'extensibility' is meant here? Extending the telepresence sessions, or= extending the specifications for new functionality in the future?

[MB] Suggestion is to reword this as:

 

REQMT-16:  The specification of any new protoco= ls for the solution MUST provide extensibility mechanisms. =

 

[/MB]



Minor issues:

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

[MB] The proposal is to expand the use of CLUE in th= e abstract as follows:

 

OLD:

   This memo discusses the requ= irements for specifications that enable

&=
nbsp;
   telepresence interoperability, by describing t=
he relationship between
   multiple RTP streams. 
NEW
&=
nbsp;
   This memo discusses the requirements for speci=
fications, that enable
&=
nbsp;
   telepresence interoperability by describing be=
haviors and protocols for Controlling   Multiple Streams for=
 Telepresence (CLUE).  

 

[/MB]


2. In the Introduction Section I see:

>  These
   requirements are for the specification, they are not requireme= nts on
   the telepresence systems implementing the solution/protocol th= at will
   be specified.

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

[MB] Agreed.  We'll add the following sentence = right before the last sentence in paragraph 1 in section 5.

 

"Note, the term "solution" is used in= these requirements to mean the protocol specifications, including extensio= ns to existing protocols as well as any new protocols,  developed to s= upport the use cases."

 

[/MB] 


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

Regards,

Dan

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

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA129DB825AZFFEXMB04globa_-- From Christian.Groves@nteczone.com Wed Dec 11 21:58:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004651AE0CF for ; Wed, 11 Dec 2013 21:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCXcvBhgRpB9 for ; Wed, 11 Dec 2013 21:58:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BBD1AE0A9 for ; Wed, 11 Dec 2013 21:58:12 -0800 (PST) Received: from ppp118-209-77-200.lns20.mel4.internode.on.net ([118.209.77.200]:61911 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VqzH7-0008A2-VT for clue@ietf.org; Thu, 12 Dec 2013 16:57:30 +1100 Message-ID: <52A95062.1010309@nteczone.com> Date: Thu, 12 Dec 2013 16:57:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "clue@ietf.org" References: <5292A5CE.4050605@nteczone.com> In-Reply-To: <5292A5CE.4050605@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [clue] Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 05:58:15 -0000 Any further questions/comments? Christian On 25/11/2013 12:20 PM, Christian Groves wrote: > Hello all, > > I'd like to pick up the discussion on roles from the last CLUE WG > meeting and try and make some progress via email before the design > team meeting. > > First i'd like to clarify that "role" is not intended to be a single > attribute and it can have different meanings. My draft > (draft-groves-clue-role-clarifications-00) seeks to clarify and > provide a terminology to be more specific. I.e.: > 2.1. Meeting Roles > 2.2. Conference System Control Roles > 2.3. Institution type > 2.4. Person Name Title > 2.5. Person Occupation (Job Title) > 2.6. Organisation Name > 2.7. Meeting Specific Roles > > Roles 2.3,2.4,2.5 and 2.6 have been grouped into a "vCard" by the > draft. 2.1 and 2.7 have also been grouped by the draft. > > There has been some concern that "roles" overlap with floor control. > From the role categories above I believe this is only relevant for > "conference system control" roles. > > Secondly the intended purpose of including "roles" into CLUE is not > for conference control or rostering but is for the selection of > Scenes/Captures and may be used for any subsequent rendering decisions > like the other CLUE attributes. The focus of the CLUE work has been to > focus on selecting captures based on technical aspects (what) e.g. > spatial properties but I think we've missed a more important aspect > that captures will depict people or entities (who). As a consumer I'm > likely to be more interested in who rather than what. For example if I > have a limited system and have received an Advertisement advertising 3 > Captures(left/centre/right) and I have only one screen so must choose > one. One could choose the centre but this is a problem if my boss is > sitting in the left capture. > > Thirdly because CLUE enhances the support of multiple streams there is > likely to be a larger set of captures being advertised. Information > about sources scenes/captures including different combinations may be > sent to a consumer providing much more choice. Each of these > scenes/captures may have different role information. Rather than try > to implement role across several different methods and introduce > dependencies between CLUE and other methods (e.g. conference package > or SDP which have no Scene/capture/MCC concepts) it is most > straightforward to send the information where it is needed i.e. in CLUE. > > Fourthly we have included the "description" parameter at the Scene,CSE > and Capture level. I think people will use those as de-facto for > "role" type information e.g. Scene Description="Company X VIC meeting > room". Rather than have a completely unstructured usage of description > I think that having "role" type information provided in a structured > form (i.e. via vCard) will at least provide a consumer the ability to > do some intelligent processing/rendering of the information. By > allowing this "role" information to be sent in a structured way via > CLUE I think will be an enabler for some interesting services and > features. > > Finally to re-iterate what the proposal is from the draft: > 1. The addition of a capture attribute "Meeting Role" attribute > with values as per section 3.1 and 3.2. > 2. The addition of a capture attribute "Conference System > Control Role" attribute with values as per section 3.3. > 3. The addition of a capture attribute "vCard" that allows one > or more vCards according to [RFC6350] to be associated with a > capture. > 4. The addition of a capture attribute "End point vCard" that > allows a "group", "org" or "location" kind of vCard according > to section 6.1.4/[RFC6350] to be associated with a capture. > > Comments? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From internet-drafts@ietf.org Thu Dec 12 11:15:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B00D1AE138; Thu, 12 Dec 2013 11:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TopBiFnzvDT; Thu, 12 Dec 2013 11:15:12 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AC71ADF87; Thu, 12 Dec 2013 11:15:12 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212191512.10780.24830.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 11:15:12 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:15:15 -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-07.txt Pages : 14 Date : 2013-12-12 Abstract: This memo discusses the requirements for specifications, that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirement= s-07 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 Thu Dec 12 11:18:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5D81AE138 for ; Thu, 12 Dec 2013 11:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZHuDvf4jplA for ; Thu, 12 Dec 2013 11:18:14 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 270FC1ADF74 for ; Thu, 12 Dec 2013 11:18:13 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so52137wiv.7 for ; Thu, 12 Dec 2013 11:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=temH69C0ituTuOSNygG39mpiHEBlGoH+6+fv3tSDMwU=; b=HVeH4WXprschO8jkWIK6+oePiFxuiGOrwSF5AD237WSoR7W8jdsDtOcedlNT21yRNd ynkYb9T17GtU1A/zx8VfnEUFXH0tK2JfOZcz+Ou4w1EJElX/c7rMUkf41FHwNqAQWIn7 SkoNWq4ssU1E5LvFVS/NNFs+tPzxhkUNkubNS59J0b71CliPKY36h9sULC4yKGw2najw TwrRk45CRuJGeaGARMzsuzl4rhtdzYj/uia7QEhgV7mCmfp7RX94GVLRjkE38mFEr8Kq 4xA0+0RTOmqIoXWieniy2CY+Xl7Q9WcAHOYghtdgC4AyZLQrL5zjMreACbL1zOKfQzSi g9Ag== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr8113937wjc.9.1386875884566; Thu, 12 Dec 2013 11:18:04 -0800 (PST) Received: by 10.216.172.9 with HTTP; Thu, 12 Dec 2013 11:18:04 -0800 (PST) In-Reply-To: <20131212191512.10780.24830.idtracker@ietfa.amsl.com> References: <20131212191512.10780.24830.idtracker@ietfa.amsl.com> Date: Thu, 12 Dec 2013 13:18:04 -0600 Message-ID: From: Mary Barnes To: CLUE , Paul Kyzivat , Gonzalo Camarillo Content-Type: multipart/alternative; boundary=047d7b873a10727d4304ed5b3410 Subject: [clue] Fwd: I-D Action: draft-ietf-clue-telepresence-requirements-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 19:18:16 -0000 --047d7b873a10727d4304ed5b3410 Content-Type: text/plain; charset=ISO-8859-1 Note, this update reflects the changes based upon Dan Romascanu's gen-art review per the email discussions: http://www.ietf.org/mail-archive/web/clue/current/msg03173.html Paul/Gonzalo - I think the document is ready for IESG review. Can you get it added to the next telechat agenda? Thanks, Mary. ---------- Forwarded message ---------- From: Date: Thu, Dec 12, 2013 at 1:15 PM Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-07.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-07.txt Pages : 14 Date : 2013-12-12 Abstract: This memo discusses the requirements for specifications, that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-07 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 --047d7b873a10727d4304ed5b3410 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note, this update reflects the changes based upon Dan Roma= scanu's gen-art review per the email discussions:

Paul/Gonzalo - I think the document is ready for = IESG review. =A0Can you get it added to the next telechat agenda?

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Thu, Dec 12, 2013 at 1:15 = PM
Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-07.tx= t
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-07.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 14
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-12

Abstract:
=A0 =A0This memo discusses the requirements for specifications, that enable=
=A0 =A0telepresence interoperability by describing behaviors and protocols<= br> =A0 =A0for Controlling Multiple Streams for Telepresence (CLUE). =A0In
=A0 =A0addition, the problem statement and related definitions are also
=A0 =A0covered 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-07

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


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

--047d7b873a10727d4304ed5b3410-- From pkyzivat@alum.mit.edu Fri Dec 13 09:36:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748401ADF6A for ; Fri, 13 Dec 2013 09:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5PWGr6jJFB for ; Fri, 13 Dec 2013 09:36:04 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8531ADF7E for ; Fri, 13 Dec 2013 09:36:04 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id 11hu1n0090Fqzac5D5bxDr; Fri, 13 Dec 2013 17:35:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 15bx1n00h3ZTu2S3U5bxbn; Fri, 13 Dec 2013 17:35:57 +0000 Message-ID: <52AB457D.4010505@alum.mit.edu> Date: Fri, 13 Dec 2013 12:35:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mary Barnes , CLUE , Gonzalo Camarillo References: <20131212191512.10780.24830.idtracker@ietfa.amsl.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=1386956157; bh=PAAyCdf/aW0bCUz7BttdLd3VIqiOU0/7Zhk6Le1u8z8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TT1Wu/bpr2vvGHjnvdTiBoxqAGsU00WQe16XeGkvNGHiYgBlUsv13sm1zHAuBO7/v QoCa0gBnc8RRYvLHaOTsTu1CvsPZ0SWKx77k25Teoy4A6pFMjF7Cp3/YVUsOyp9lbm R1jyzviDjM2SYec11qYhp59nYg/8Ld2KhPBNjI86GMl6QsL89ozoh5GzFcAhcKfthF hTwq8epT4p7CcygAjz/pmEiix9i12jnLmyL49LsoRKEQKsW39KxAT59IbgD2YPQilK PFJ2rQJEKtNpJezYlZsNfcvX0EyYh43Yaj09VAyL80nQIYtR45FbX1xXBDX1ZS+Yun zmlOXHK3PWuGg== Subject: Re: [clue] Fwd: I-D Action: draft-ietf-clue-telepresence-requirements-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:36:06 -0000 On 12/12/13 2:18 PM, Mary Barnes wrote: > Note, this update reflects the changes based upon Dan Romascanu's > gen-art review per the email discussions: > http://www.ietf.org/mail-archive/web/clue/current/msg03173.html > > Paul/Gonzalo - I think the document is ready for IESG review. WFM Thanks, Paul > Can you > get it added to the next telechat agenda? > Thanks, > Mary. > > ---------- Forwarded message ---------- > From: ** > > Date: Thu, Dec 12, 2013 at 1:15 PM > Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-07.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-07.txt > Pages : 14 > Date : 2013-12-12 > > Abstract: > This memo discusses the requirements for specifications, that enable > telepresence interoperability by describing behaviors and protocols > for Controlling Multiple Streams for Telepresence (CLUE). In > addition, the problem statement and related definitions are also > covered herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-07 > > > 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 > From Christian.Groves@nteczone.com Sun Dec 15 20:08:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801EB1AE075 for ; Sun, 15 Dec 2013 20:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk0o1bdHCtOY for ; Sun, 15 Dec 2013 20:08:41 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55FC21AE2A1 for ; Sun, 15 Dec 2013 20:08:41 -0800 (PST) Received: from ppp118-209-168-53.lns20.mel6.internode.on.net ([118.209.168.53]:57772 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VsPSZ-0004Sj-8K for clue@ietf.org; Mon, 16 Dec 2013 15:07:11 +1100 Message-ID: <52AE7CC5.4040001@nteczone.com> Date: Mon, 16 Dec 2013 15:08:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: [clue] CLUE Roles and SIP Conference Events X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 04:08:49 -0000 Hello all, There have been some thoughts that the Conference Framework is more appropriate to carry the role information associated with captures. I don't believe it is. I've provided my thoughts on this before the design meeting this week. Structure from RFC 4575 ----------------------- conference-info | |-- conference-description | |-- host-info | |-- conference-state | |-- users | |-- user | | |-- endpoint | | | |-- media | | | |-- media | | | |-- call-info The structure is not optimal for describing the people in captures. i.e. if I have 3 people being depicted by a single stream. If users actually represented the persons within the media (which I contend it does not) it would have three user structures pointing to the same media stream. The XML schema in RFC4575 only allows for one display-text(name) and role per user-type. RFC 4575 Section 5.6 - this appears to be related to who owns the endpoint NOT who is contained in the media. i.e. the conference framework indicates that the users must have a unique URI in the conference. This view appears to also be supported by section 6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON data schema). It seems non-nonsensical that all the people depicted in the conference all have a URI associated with them. Therefore it doesn't seem appropriate to use the "user" structure to represent all the people within a single media. The usage of "roles" from RFC 4575 is not appropriate because it relates to the owner of the endpoint not the people displayed in the media capture encoding. In order to have Capture Scene/Captures in the Conferencing framework the information would be need to be added under the endpoint, i.e. | |-- user | |-- endpoint | |-- media | |-- capture_scene | |--capture1 | |--capture2 | |--capturex These concepts would have to be included into the conferencing framework before CLUE role information could be provided. However this could mean a several year delay in adding "role" information because it's not in the scope of the CLUE WG. If it was decided to follow this route, the captures could provide a label to correlate to the media in the above structure. This structure would effectively mirror what is in a CLUE Advertisement (Its not clear what the benefit would be for duplicating the information). The complicating factor is that the conference focus (MCU) may CLUE Advertise different captures than what was originally advertised from the source Endpoints. i.e. the MCU may compose/switch streams. Therefore the information about the captures from the Endpoint (i.e. role) may be different from what is received by a Consumer in an Advertisement. This would be problematic for a Consumer to try to correlate the information from the Conference Event Package to what it actually receives in the CLUE Advertisement for the purpose Capture selection based on the role information. A further complication is the relationship between the CLUE messages and any SIP subscribes/Notifies related to the Capture Scene /Capture / Role information. There would be race conditions regarding when the Conference Package data is received vs when an CLUE Advertisement is received vs the reception of updated SDP Offer/Answers. This co-ordination would be non-trivial. To avoid this situation it's appropriate to provide information regarding captures (including the role information) in the CLUE messages as it relates to the people in the captures and removes any interaction issues. It also must be remembered that the Capture attributes are intended for processing by automata and/or humans. The focus of the Conference Event framework is purely with respect to endpoint and media information as per RFC4575 Sect 5.1 is "..., and are intended for display to human subscribers only". The intent of the "role" information in CLUE is to allow for processing by automata. RFC4575 Section 5.6.3 there is no definition of what this is other than a set of strings. Its only for human consumption. RFC6501 section 4.6.5.2 does provide some values for "role" but these do not cover vCard type information nor the full set of conference roles. Also given the scope issue raised above it wouldn't be possible to indicate the people within the capture. Furthermore CLUE is meant for use in point to point and multi-point environments. So far it has been designed to be largely independent from other protocols. i.e. its not coupled to BUNDLE and the encoding information is separate. The conference framework may or may not be used depending on the call or network scenario. Therefore it doesn't seem wise to place capture attribute information such as "role" information only in the Conference Event Package. This would mean that the role information could only be used in a limited sub-set of scenarios. Therefore I believe its appropriate to add role in CLUE at this time. Comments? Regards, Christian From spromano@unina.it Tue Dec 17 00:38:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B781AE125 for ; Tue, 17 Dec 2013 00:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQDVxB09ck1T for ; Tue, 17 Dec 2013 00:38:52 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9A56E1AE0A2 for ; Tue, 17 Dec 2013 00:38:51 -0800 (PST) Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id rBH8cmjE030394 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Dec 2013 09:38:49 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_046A642B-BEB7-4D4F-93B6-BC386F8ED215" From: Simon Pietro Romano In-Reply-To: <52AE7CC5.4040001@nteczone.com> Date: Tue, 17 Dec 2013 09:39:26 +0100 Message-Id: <363388D4-8714-4A5A-88C9-CAD379E8FA35@unina.it> References: <52AE7CC5.4040001@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1283) Cc: "clue@ietf.org" Subject: Re: [clue] CLUE Roles and SIP Conference Events X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 08:38:55 -0000 --Apple-Mail=_046A642B-BEB7-4D4F-93B6-BC386F8ED215 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello Christian and all, when it comes to role management, I have multiple times expressed my = concerns with respect to its direct inclusion in 'orthogonal' structures = (like data model, conference information and the like). You might want = to have a look at a specific thread dedicated to policies and roles = inside XCON, back in 2007. I expressed my personal view on this subject = in a (long) e-mail = (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html). I = keep on thinking that we should definitely try and adhere to the = well-known design pattern associated with the concept of separation of = concerns and use something like XACML to express role information inside = CLUE. My two cents, Simon Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha scritto: > Hello all, >=20 > There have been some thoughts that the Conference Framework is more = appropriate to carry the role information associated with captures. I = don't believe it is. I've provided my thoughts on this before the design = meeting this week. >=20 > Structure from RFC 4575 > ----------------------- > conference-info > | > |-- conference-description > | > |-- host-info > | > |-- conference-state > | > |-- users > | |-- user > | | |-- endpoint > | | | |-- media > | | | |-- media > | | | |-- call-info >=20 >=20 > The structure is not optimal for describing the people in captures. = i.e. if I have 3 people being depicted by a single stream. If users = actually represented the persons within the media (which I contend it = does not) it would have three user structures pointing to the same media = stream. The XML schema in RFC4575 only allows for one display-text(name) = and role per user-type. >=20 > RFC 4575 Section 5.6 - this appears to be related to who owns = the endpoint NOT who is contained in the media. i.e. the conference = framework indicates that the users must have a unique URI in the = conference. This view appears to also be supported by section = 6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON data = schema). It seems non-nonsensical that all the people depicted in the = conference all have a URI associated with them. Therefore it doesn't = seem appropriate to use the "user" structure to represent all the people = within a single media. The usage of "roles" from RFC 4575 is not = appropriate because it relates to the owner of the endpoint not the = people displayed in the media capture encoding. >=20 > In order to have Capture Scene/Captures in the Conferencing framework = the information would be need to be added under the endpoint, i.e. >=20 > | |-- user > | |-- endpoint > | |-- media > | |-- capture_scene > | |--capture1 > | |--capture2 > | |--capturex >=20 > These concepts would have to be included into the conferencing = framework before CLUE role information could be provided. However this = could mean a several year delay in adding "role" information because = it's not in the scope of the CLUE WG. If it was decided to follow this = route, the captures could provide a label to correlate to the media in = the above structure. This structure would effectively mirror what is in = a CLUE Advertisement (Its not clear what the benefit would be for = duplicating the information). The complicating factor is that the = conference focus (MCU) may CLUE Advertise different captures than what = was originally advertised from the source Endpoints. i.e. the MCU may = compose/switch streams. Therefore the information about the captures = from the Endpoint (i.e. role) may be different from what is received by = a Consumer in an Advertisement. This would be problematic for a Consumer = to try to correlate the information from the Conference Event Package to = what it actually receives in the CLUE Advertisement for the purpose = Capture selection based on the role information. >=20 > A further complication is the relationship between the CLUE messages = and any SIP subscribes/Notifies related to the Capture Scene /Capture / = Role information. There would be race conditions regarding when the = Conference Package data is received vs when an CLUE Advertisement is = received vs the reception of updated SDP Offer/Answers. This = co-ordination would be non-trivial. >=20 > To avoid this situation it's appropriate to provide information = regarding captures (including the role information) in the CLUE messages = as it relates to the people in the captures and removes any interaction = issues. >=20 > It also must be remembered that the Capture attributes are intended = for processing by automata and/or humans. The focus of the Conference = Event framework is purely with respect to endpoint and media information = as per RFC4575 Sect 5.1 is "..., and are intended for = display to human subscribers only". The intent of the "role" information = in CLUE is to allow for processing by automata. RFC4575 Section 5.6.3 = there is no definition of what this is other than a set of strings. Its = only for human consumption. RFC6501 section 4.6.5.2 does provide some = values for "role" but these do not cover vCard type information nor the = full set of conference roles. Also given the scope issue raised above it = wouldn't be possible to indicate the people within the capture. >=20 > Furthermore CLUE is meant for use in point to point and multi-point = environments. So far it has been designed to be largely independent from = other protocols. i.e. its not coupled to BUNDLE and the encoding = information is separate. The conference framework may or may not be used = depending on the call or network scenario. Therefore it doesn't seem = wise to place capture attribute information such as "role" information = only in the Conference Event Package. This would mean that the role = information could only be used in a limited sub-set of scenarios. >=20 > Therefore I believe its appropriate to add role in CLUE at this time. >=20 > Comments? >=20 > Regards, Christian >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_046A642B-BEB7-4D4F-93B6-BC386F8ED215 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = Christian and all,

when it comes to role management, = I have multiple times expressed my concerns with respect to its direct = inclusion in 'orthogonal' structures (like data model, conference = information and the like). You might want to have a look at a = specific thread dedicated to policies and roles inside XCON, back in = 2007. I expressed my personal view on this subject in a (long) e-mail = (h= ttp://www.ietf.org/mail-archive/web/xcon/current/msg01919.html). I = keep on thinking that we should definitely try and adhere to the = well-known design pattern associated with the concept of separation of = concerns and use something like XACML to express role information inside = CLUE.

My two = cents,

Simon


Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha = scritto:

Hello all,

There have been some thoughts that = the Conference Framework is more appropriate to carry the role = information associated with captures. I don't believe it is. I've = provided my thoughts on this before the design meeting this = week.

Structure from RFC 4575
-----------------------
= conference-info
    |
=     |-- conference-description
=     |
    |-- host-info
=     |
    |-- = conference-state
    |
=     |-- users
    | =    |-- user
    | =    |    |-- endpoint
=     |    |    | =    |-- media
    | =    |    |    |-- media
=     |    |    | =    |-- call-info


The structure is not optimal = for describing the people in captures. i.e. if I have 3 people being = depicted by a single stream. If users actually represented the persons = within the media (which I contend it does not) it would have three user = structures pointing to the same media stream. The XML schema in RFC4575 = only allows for one display-text(name) and role per = user-type.

RFC 4575 Section 5.6 <users> - this appears to = be related to who owns the endpoint NOT who is contained in the media. = i.e. the conference framework indicates that the users must have a = unique URI in the conference. This view appears to also be supported by = section 6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON = data schema). It seems non-nonsensical that all the people depicted in = the conference all have a URI associated with them. Therefore it doesn't = seem appropriate to use the "user" structure to represent all the people = within a single media. The usage of "roles" from RFC 4575 is not = appropriate because it relates to the owner of the endpoint not the = people displayed in the media capture encoding.

In order to have = Capture Scene/Captures in the Conferencing framework the information = would be need to be added under the endpoint, i.e.

=     |    |-- user
=     | =         |-- endpoint
=     | =             &n= bsp;|-- media
    | =             &n= bsp;|-- capture_scene
    | =             &n= bsp;     |--capture1
=     | =             &n= bsp;     |--capture2
=     | =             &n= bsp;     |--capturex

These concepts = would have to be included into the conferencing framework before CLUE = role information could be provided. However this could mean a several = year delay in adding "role" information because it's not in the scope of = the CLUE WG. If it was decided to follow this route, the captures could = provide a label to correlate to the media in the above structure. This = structure would effectively mirror what is in a CLUE Advertisement (Its = not clear what the benefit would be for duplicating the information). = The complicating factor is that the conference focus (MCU) may CLUE = Advertise different captures than what was originally advertised from = the source Endpoints. i.e. the MCU may compose/switch streams. Therefore = the information about the captures from the Endpoint (i.e. role) may be = different from what is received by a Consumer in an Advertisement. This = would be problematic for a Consumer to try to correlate the information = from the Conference Event Package to what it actually receives in the = CLUE Advertisement for the purpose Capture selection based on the role = information.

A further complication is the relationship between = the CLUE messages and any SIP subscribes/Notifies related to the Capture = Scene /Capture / Role information. There would be race conditions = regarding when the Conference Package data is received vs when an CLUE = Advertisement is received vs the reception of updated SDP Offer/Answers. = This co-ordination would be non-trivial.

To avoid this situation = it's appropriate to provide information regarding captures (including = the role information) in the CLUE messages as it relates to the people = in the captures and removes any interaction issues.

It also must = be remembered that the Capture attributes are intended for processing by = automata and/or humans. The focus of the Conference Event framework is = purely with respect to endpoint and media information as per RFC4575 = Sect 5.1 is "...<endpoint>, and <media> are intended for = display to human subscribers only". The intent of the "role" information = in CLUE is to allow for processing by automata. RFC4575 Section 5.6.3 = there is no definition of what this is other than a set of strings. Its = only for human consumption. RFC6501 section 4.6.5.2 does provide some = values for "role" but these do not cover vCard type information nor the = full set of conference roles. Also given the scope issue raised above it = wouldn't be possible to indicate the people within the = capture.

Furthermore CLUE is meant for use in point to point and = multi-point environments. So far it has been designed to be largely = independent from other protocols. i.e. its not coupled to BUNDLE and the = encoding information is separate. The conference framework may or may = not be used depending on the call or network scenario. Therefore it = doesn't seem wise to place capture attribute information such as "role" = information only in the Conference Event Package. This would mean that = the role information could only be used in a limited sub-set of = scenarios.

Therefore I believe its appropriate to add role in = CLUE at this time.

Comments?

Regards, = Christian

_______________________________________________
clue = mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue


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

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





= --Apple-Mail=_046A642B-BEB7-4D4F-93B6-BC386F8ED215-- From Christian.Groves@nteczone.com Tue Dec 17 02:09:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771861AE134 for ; Tue, 17 Dec 2013 02:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M6yRWxuBsYg for ; Tue, 17 Dec 2013 02:09:07 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E6D1ADFBE for ; Tue, 17 Dec 2013 02:09:05 -0800 (PST) Received: from ppp118-209-29-32.lns20.mel4.internode.on.net ([118.209.29.32]:60717 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VsraC-0005cv-Pq; Tue, 17 Dec 2013 21:08:56 +1100 Message-ID: <52B022BC.8020501@nteczone.com> Date: Tue, 17 Dec 2013 21:09:00 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Simon Pietro Romano References: <52AE7CC5.4040001@nteczone.com> <363388D4-8714-4A5A-88C9-CAD379E8FA35@unina.it> In-Reply-To: <363388D4-8714-4A5A-88C9-CAD379E8FA35@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Cc: "clue@ietf.org" Subject: Re: [clue] CLUE Roles and SIP Conference Events X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 10:09:10 -0000 Hello Simon, I had a look at the email you referred to and XACML. I think these are far beyond what I'm currently proposing with respect to "role" in CLUE. The work you refer to seems to be related to policy and conference control. This is not the intention behind my proposal for vCard and meeting roles (generically know as roles). There may be some overlap with what I describe as conference roles with floor control. Unfortunately it seems "Role" is a loaded word. I think if we had called it "participant information" from the start there wouldn't be many concerns... The intention is to provide information about who is in each capture for the purpose selection of captures and possible rendering. These do not provide any permissions or control from a conference perspective. I think such "control/policy" aspects are best left outside of CLUE. What i'd like to see is that the information needed for a protocol is self contained. I.e. you have all the information needed for scene/captures selection in CLUE, for policy/conferencing rolls that could be described as you mentioned above, for conference state its covered by the SIP conferencing framework, encoding information is kept in SDP etc. Regards, Christian On 17/12/2013 7:39 PM, Simon Pietro Romano wrote: > Hello Christian and all, > > when it comes to role management, I have multiple times expressed my > concerns with respect to its direct inclusion in 'orthogonal' > structures (like data model, conference information and the like). You > might want to have a look at a specific thread dedicated to policies > and roles inside XCON, back in 2007. I expressed my personal view on > this subject in a (long) e-mail > (http://www.ietf.org/mail-archive/web/xcon/current/msg01919.html). I > keep on thinking that we should definitely try and adhere to the > well-known design pattern associated with the concept of separation of > concerns and use something like XACML to express role information > inside CLUE. > > My two cents, > > Simon > > > Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha scritto: > >> Hello all, >> >> There have been some thoughts that the Conference Framework is more >> appropriate to carry the role information associated with captures. I >> don't believe it is. I've provided my thoughts on this before the >> design meeting this week. >> >> Structure from RFC 4575 >> ----------------------- >> conference-info >> | >> |-- conference-description >> | >> |-- host-info >> | >> |-- conference-state >> | >> |-- users >> | |-- user >> | | |-- endpoint >> | | | |-- media >> | | | |-- media >> | | | |-- call-info >> >> >> The structure is not optimal for describing the people in captures. >> i.e. if I have 3 people being depicted by a single stream. If users >> actually represented the persons within the media (which I contend it >> does not) it would have three user structures pointing to the same >> media stream. The XML schema in RFC4575 only allows for one >> display-text(name) and role per user-type. >> >> RFC 4575 Section 5.6 - this appears to be related to who owns >> the endpoint NOT who is contained in the media. i.e. the conference >> framework indicates that the users must have a unique URI in the >> conference. This view appears to also be supported by section >> 6.3/RFC5239 (XCON framework) and section 4.6.5/RFC6501 (XCON data >> schema). It seems non-nonsensical that all the people depicted in the >> conference all have a URI associated with them. Therefore it doesn't >> seem appropriate to use the "user" structure to represent all the >> people within a single media. The usage of "roles" from RFC 4575 is >> not appropriate because it relates to the owner of the endpoint not >> the people displayed in the media capture encoding. >> >> In order to have Capture Scene/Captures in the Conferencing framework >> the information would be need to be added under the endpoint, i.e. >> >> | |-- user >> | |-- endpoint >> | |-- media >> | |-- capture_scene >> | |--capture1 >> | |--capture2 >> | |--capturex >> >> These concepts would have to be included into the conferencing >> framework before CLUE role information could be provided. However >> this could mean a several year delay in adding "role" information >> because it's not in the scope of the CLUE WG. If it was decided to >> follow this route, the captures could provide a label to correlate to >> the media in the above structure. This structure would effectively >> mirror what is in a CLUE Advertisement (Its not clear what the >> benefit would be for duplicating the information). The complicating >> factor is that the conference focus (MCU) may CLUE Advertise >> different captures than what was originally advertised from the >> source Endpoints. i.e. the MCU may compose/switch streams. Therefore >> the information about the captures from the Endpoint (i.e. role) may >> be different from what is received by a Consumer in an Advertisement. >> This would be problematic for a Consumer to try to correlate the >> information from the Conference Event Package to what it actually >> receives in the CLUE Advertisement for the purpose Capture selection >> based on the role information. >> >> A further complication is the relationship between the CLUE messages >> and any SIP subscribes/Notifies related to the Capture Scene /Capture >> / Role information. There would be race conditions regarding when the >> Conference Package data is received vs when an CLUE Advertisement is >> received vs the reception of updated SDP Offer/Answers. This >> co-ordination would be non-trivial. >> >> To avoid this situation it's appropriate to provide information >> regarding captures (including the role information) in the CLUE >> messages as it relates to the people in the captures and removes any >> interaction issues. >> >> It also must be remembered that the Capture attributes are intended >> for processing by automata and/or humans. The focus of the Conference >> Event framework is purely with respect to endpoint and media >> information as per RFC4575 Sect 5.1 is "..., and >> are intended for display to human subscribers only". The intent of >> the "role" information in CLUE is to allow for processing by >> automata. RFC4575 Section 5.6.3 there is no definition of what this >> is other than a set of strings. Its only for human consumption. >> RFC6501 section 4.6.5.2 does provide some values for "role" but these >> do not cover vCard type information nor the full set of conference >> roles. Also given the scope issue raised above it wouldn't be >> possible to indicate the people within the capture. >> >> Furthermore CLUE is meant for use in point to point and multi-point >> environments. So far it has been designed to be largely independent >> from other protocols. i.e. its not coupled to BUNDLE and the encoding >> information is separate. The conference framework may or may not be >> used depending on the call or network scenario. Therefore it doesn't >> seem wise to place capture attribute information such as "role" >> information only in the Conference Event Package. This would mean >> that the role information could only be used in a limited sub-set of >> scenarios. >> >> Therefore I believe its appropriate to add role in CLUE at this time. >> >> Comments? >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > From mary.ietf.barnes@gmail.com Tue Dec 17 08:00:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0711AE1B0 for ; Tue, 17 Dec 2013 08:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6pvXLNHYMpT for ; Tue, 17 Dec 2013 08:00:24 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6F41AE1B2 for ; Tue, 17 Dec 2013 08:00:23 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so3942997wib.15 for ; Tue, 17 Dec 2013 08:00:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5w4ZCUHG5dBPdSwG/hK68RfMLpdBm8xRq6CaFTrmgow=; b=cHem6WQA2tP2H6x9VEGElDwuLXfM5CWUI/2dKzmf0lMGOsvCt/1tWHkw+oay+bbGXQ K/mV0Mip4JLorJ//7gcjFEEmZtUhQ3Za76XrSKNSOc/tmFNCKfA/ag6w/lhWR0Z98lio /JKZ1Fu+7aiQOLdnf3hG4YDwEYsmjcC3xxGk82X4rgD4NSYhbvp9jj3mHalFwnfz8+Ws xcp89DZcxHfPzR0kJfzYyBFLbKkDuUxDwAJEE835ijsTh+JAMiWT1NJ616vQRvtchXtR 0JPmWQkLFpoz1W/PuiZrHeyj00exhmvzNE3aC8f7gEKsTw1E+ZffEhOarxZLNrOlQKJe 8mIA== MIME-Version: 1.0 X-Received: by 10.180.93.8 with SMTP id cq8mr3923422wib.38.1387296021733; Tue, 17 Dec 2013 08:00:21 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 17 Dec 2013 08:00:21 -0800 (PST) In-Reply-To: <52B022BC.8020501@nteczone.com> References: <52AE7CC5.4040001@nteczone.com> <363388D4-8714-4A5A-88C9-CAD379E8FA35@unina.it> <52B022BC.8020501@nteczone.com> Date: Tue, 17 Dec 2013 10:00:21 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=f46d043892b192f0d604edbd0614 Cc: "clue@ietf.org" Subject: Re: [clue] CLUE Roles and SIP Conference Events X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 16:00:29 -0000 --f46d043892b192f0d604edbd0614 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Individual opinions below [MB]. Mary. On Tue, Dec 17, 2013 at 4:09 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Simon, > > I had a look at the email you referred to and XACML. I think these are fa= r > beyond what I'm currently proposing with respect to "role" in CLUE. The > work you refer to seems to be related to policy and conference control. > This is not the intention behind my proposal for vCard and meeting roles > (generically know as roles). There may be some overlap with what I descri= be > as conference roles with floor control. Unfortunately it seems "Role" is = a > loaded word. I think if we had called it "participant information" from t= he > start there wouldn't be many concerns... > > The intention is to provide information about who is in each capture for > the purpose selection of captures and possible rendering. These do not > provide any permissions or control from a conference perspective. I think > such "control/policy" aspects are best left outside of CLUE. > > What i'd like to see is that the information needed for a protocol is sel= f > contained. I.e. you have all the information needed for scene/captures > selection in CLUE, for policy/conferencing rolls that could be described = as > you mentioned above, for conference state its covered by the SIP > conferencing framework, encoding information is kept in SDP etc. > [MB] Right. And, SIP conferencing has an event package/data model that defines roles. There are a number of folks that don't implement CCMP, but they still use the XCON data model as it provides a richer set of information. My personal preference is that the XCON data model be extended to handle roles in the context of multi-streams. [/MB] > > Regards, Christian > > > On 17/12/2013 7:39 PM, Simon Pietro Romano wrote: > >> Hello Christian and all, >> >> when it comes to role management, I have multiple times expressed my >> concerns with respect to its direct inclusion in 'orthogonal' structures >> (like data model, conference information and the like). You might want t= o >> have a look at a specific thread dedicated to policies and roles inside >> XCON, back in 2007. I expressed my personal view on this subject in a >> (long) e-mail (http://www.ietf.org/mail-archive/web/xcon/current/ >> msg01919.html). I keep on thinking that we should definitely try and >> adhere to the well-known design pattern associated with the concept of >> separation of concerns and use something like XACML to express role >> information inside CLUE. >> >> My two cents, >> >> Simon >> >> >> Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha scritto: >> >> Hello all, >>> >>> There have been some thoughts that the Conference Framework is more >>> appropriate to carry the role information associated with captures. I d= on't >>> believe it is. I've provided my thoughts on this before the design meet= ing >>> this week. >>> >>> Structure from RFC 4575 >>> ----------------------- >>> conference-info >>> | >>> |-- conference-description >>> | >>> |-- host-info >>> | >>> |-- conference-state >>> | >>> |-- users >>> | |-- user >>> | | |-- endpoint >>> | | | |-- media >>> | | | |-- media >>> | | | |-- call-info >>> >>> >>> The structure is not optimal for describing the people in captures. i.e= . >>> if I have 3 people being depicted by a single stream. If users actually >>> represented the persons within the media (which I contend it does not) = it >>> would have three user structures pointing to the same media stream. The= XML >>> schema in RFC4575 only allows for one display-text(name) and role per >>> user-type. >>> >> [MB] I suggest you look at RFC 6501. [/MB] > >>> RFC 4575 Section 5.6 - this appears to be related to who owns >>> the endpoint NOT who is contained in the media. i.e. the conference >>> framework indicates that the users must have a unique URI in the >>> conference. This view appears to also be supported by section 6.3/RFC52= 39 >>> (XCON framework) and section 4.6.5/RFC6501 (XCON data schema). It seems >>> non-nonsensical that all the people depicted in the conference all have= a >>> URI associated with them. >>> >> [MB] I don't think that's at all non-sensical. That's normal SIP processing and SIP conferencing. [/MB] > Therefore it doesn't seem appropriate to use the "user" structure to >>> represent all the people within a single media. The usage of "roles" fr= om >>> RFC 4575 is not appropriate because it relates to the owner of the endp= oint >>> not the people displayed in the media capture encoding. >>> >>> In order to have Capture Scene/Captures in the Conferencing framework >>> the information would be need to be added under the endpoint, i.e. >>> >>> | |-- user >>> | |-- endpoint >>> | |-- media >>> | |-- capture_scene >>> | |--capture1 >>> | |--capture2 >>> | |--capturex >>> >>> These concepts would have to be included into the conferencing framewor= k >>> before CLUE role information could be provided. >>> >> [MB] Not necessarily. The data model is extensible and you can make som= e of the information optional (but required for a CLUE endpoint. [/MB] > However this could mean a several year delay in adding "role" information >>> because it's not in the scope of the CLUE WG. >>> >> [MB] I certainly don't think so. We've added additional extensions to the XCON data model recently and it doesn't take several years. The design is intended to support extensibility and we should be able to progress these extensions in parallel with CLUE. [/MB] > If it was decided to follow this route, the captures could provide a labe= l >>> to correlate to the media in the above structure. This structure would >>> effectively mirror what is in a CLUE Advertisement (Its not clear what = the >>> benefit would be for duplicating the information). The complicating fac= tor >>> is that the conference focus (MCU) may CLUE Advertise different capture= s >>> than what was originally advertised from the source Endpoints. i.e. the= MCU >>> may compose/switch streams. Therefore the information about the capture= s >>> from the Endpoint (i.e. role) may be different from what is received by= a >>> Consumer in an Advertisement. This would be problematic for a Consumer = to >>> try to correlate the information from the Conference Event Package to w= hat >>> it actually receives in the CLUE Advertisement for the purpose Capture >>> selection based on the role information. >>> >> [MB] The reality is that a CLUE implementation will have to correlate some of this information, but those are implementation details that we can provide guidance on but would be non-normative. Call Flows are a really good place to illustrate this sort of thing. [/MB] > >>> A further complication is the relationship between the CLUE messages an= d >>> any SIP subscribes/Notifies related to the Capture Scene /Capture / Rol= e >>> information. There would be race conditions regarding when the Conferen= ce >>> Package data is received vs when an CLUE Advertisement is received vs t= he >>> reception of updated SDP Offer/Answers. This co-ordination would be >>> non-trivial. >>> >> >>> To avoid this situation it's appropriate to provide information >>> regarding captures (including the role information) in the CLUE message= s as >>> it relates to the people in the captures and removes any interaction is= sues. >>> >> [MB] If we do that, you then need to explain the relationship between this information and role information in the event package and still ensure that it's consistent. Again, CLUE is based on SIP/SIP conferencing. We must ensure that there's consistency in information. So, your proposal moves the problem around and adds unnecessary complexity to CLUE that isn't required for fundamental multi-stream processing. It's certainly useful information for the application, but not fundamental to CLUE deliverables (just as rosters are out of scope). [/MB] > >>> It also must be remembered that the Capture attributes are intended for >>> processing by automata and/or humans. The focus of the Conference Event >>> framework is purely with respect to endpoint and media information as p= er >>> RFC4575 Sect 5.1 is "..., and are intended for displa= y to >>> human subscribers only". >>> >> [MB] And, I think that's actually an error in RFC 4575. If you read further, it notes that is used to [/MB] > The intent of the "role" information in CLUE is to allow for processing b= y >>> automata. RFC4575 Section 5.6.3 there is no definition of what this is >>> other than a set of strings. Its only for human consumption. RFC6501 >>> section 4.6.5.2 does provide some values for "role" but these do not co= ver >>> vCard type information nor the full set of conference roles. >>> >> [MB] Certainly, but it could be extended to include such. Personally, I don't think this is crucial to the CLUE deliverables at this point. We could certainly do extensions later, once we get the basic CLUE stuff done (which I believe (putting on my chair hat) is a much higher priority than adding this element) [/MB] > Also given the scope issue raised above it wouldn't be possible to >>> indicate the people within the capture. >>> >>> Furthermore CLUE is meant for use in point to point and multi-point >>> environments. So far it has been designed to be largely independent fro= m >>> other protocols. i.e. its not coupled to BUNDLE and the encoding >>> information is separate. >>> >> [MB] It's not directly coupled, but CLUE is coupled with SDP based upon the decision to include the encoding limits in SDP. [/MB] > The conference framework may or may not be used depending on the call or >>> network scenario. Therefore it doesn't seem wise to place capture attri= bute >>> information such as "role" information only in the Conference Event >>> Package. This would mean that the role information could only be used i= n a >>> limited sub-set of scenarios. >>> >> [MB] That is certainly a valid point, but I still contend that this is not something that is NOT specific to CLUE or multi-stream in general. Also, as I've said before, this issue has been raised generally in DISPATCH: http://www.ietf.org/mail-archive/web/dispatch/current/msg04805.html Now, if this were something fundamental to CLUE, then I would fully agree that solving the problem just for CLUE is the right thing to do, but it's not, so I think working on something more general and then later extending CLUE is a much better option at this juncture. [/MB] > >>> Therefore I believe its appropriate to add role in CLUE at this time. >>> >>> Comments? >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d043892b192f0d604edbd0614 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Individual opinions below [MB].

Mary.


On Tue, Dec= 17, 2013 at 4:09 AM, Christian Groves <Christian.Groves@ntecz= one.com> wrote:
Hello Simon,

I had a look at the email you referred to and XACML. I think these are far = beyond what I'm currently proposing with respect to "role" in= CLUE. The work you refer to seems to be related to policy and conference c= ontrol. This is not the intention behind my proposal for vCard and meeting = roles (generically know as roles). There may be some overlap with what I de= scribe as conference roles with floor control. Unfortunately it seems "= ;Role" is a loaded word. I think if we had called it "participant= information" from the start there wouldn't be many concerns...
The intention is to provide information about who is in each capture for th= e purpose selection of captures and possible rendering. These do not provid= e any permissions or control from a conference perspective. I think such &q= uot;control/policy" aspects are best left outside of CLUE.

What i'd like to see is that the information needed for a protocol is s= elf contained. I.e. you have all the information needed for scene/captures = selection in CLUE, for policy/conferencing rolls that could be described as= you mentioned above, for conference state its covered by the SIP conferenc= ing framework, encoding information is kept in SDP etc.
[MB] Right. And, SIP conferencing has an event package/da= ta model that defines roles. =A0There are a number of folks that don't = implement CCMP, but they still use the XCON data model as it provides a ric= her set of information. =A0 =A0My personal preference is that the XCON data= model be extended to handle roles in the context of multi-streams. =A0[/MB= ]=A0

Regards, Christian


On 17/12/2013 7:39 PM, Simon Pietro Romano wrote:
Hello Christian and all,

when it comes to role management, I have multiple times expressed my concer= ns with respect to its direct inclusion in 'orthogonal' structures = (like data model, conference information and the like). You might want to h= ave a look at a specific thread dedicated to policies and roles inside XCON= , back in 2007. I expressed my personal view on this subject in a (long) e-= mail (http://www.ietf.org/mail-archive/web/xcon/c= urrent/msg01919.html). I keep on thinking that we should definit= ely try and adhere to the well-known design pattern associated with the con= cept of separation of concerns and use something like XACML to express role= information inside CLUE.

My two cents,

Simon


Il giorno 16/dic/2013, alle ore 05:08, Christian Groves ha scritto:

Hello all,

There have been some thoughts that the Conference Framework is more appropr= iate to carry the role information associated with captures. I don't be= lieve it is. I've provided my thoughts on this before the design meetin= g this week.

Structure from RFC 4575
-----------------------
conference-info
=A0 =A0 |
=A0 =A0 |-- conference-description
=A0 =A0 |
=A0 =A0 |-- host-info
=A0 =A0 |
=A0 =A0 |-- conference-state
=A0 =A0 |
=A0 =A0 |-- users
=A0 =A0 | =A0 =A0|-- user
=A0 =A0 | =A0 =A0| =A0 =A0|-- endpoint
=A0 =A0 | =A0 =A0| =A0 =A0| =A0 =A0|-- media
=A0 =A0 | =A0 =A0| =A0 =A0| =A0 =A0|-- media
=A0 =A0 | =A0 =A0| =A0 =A0| =A0 =A0|-- call-info


The structure is not optimal for describing the people in captures. i.e. if= I have 3 people being depicted by a single stream. If users actually repre= sented the persons within the media (which I contend it does not) it would = have three user structures pointing to the same media stream. The XML schem= a in RFC4575 only allows for one display-text(name) and role per user-type.=
[MB] I suggest you = look at RFC 6501. [/MB]=A0

RFC 4575 Section 5.6 <users> - this appears to be related to who owns= the endpoint NOT who is contained in the media. i.e. the conference framew= ork indicates that the users must have a unique URI in the conference. This= view appears to also be supported by section 6.3/RFC5239 (XCON framework) = and section 4.6.5/RFC6501 (XCON data schema). It seems non-nonsensical that= all the people depicted in the conference all have a URI associated with t= hem.
[MB] I don't think th= at's at all non-sensical. That's normal SIP processing and SIP conf= erencing. =A0 [/MB]=A0
Therefore it doesn't seem appropriate to use the= "user" structure to represent all the people within a single med= ia. The usage of "roles" from RFC 4575 is not appropriate because= it relates to the owner of the endpoint not the people displayed in the me= dia capture encoding.

In order to have Capture Scene/Captures in the Conferencing framework the i= nformation would be need to be added under the endpoint, i.e.

=A0 =A0 | =A0 =A0|-- user
=A0 =A0 | =A0 =A0 =A0 =A0 |-- endpoint
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0|-- media
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0|-- capture_scene
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--capture1
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--capture2
=A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |--capturex

These concepts would have to be included into the conferencing framework be= fore CLUE role information could be provided.
[MB] Not necessarily. =A0The data model is exten= sible and you can make some of the information optional (but required for a= CLUE endpoint. =A0[/MB]=A0
However this could mean a several y= ear delay in adding "role" information because it's not in th= e scope of the CLUE WG.
[MB] I certainly don'= t think so. =A0We've added additional extensions to the XCON data model= recently and it doesn't take several years. The design is intended to = support extensibility and we should be able to progress these extensions in= parallel with CLUE. =A0
[/MB]=A0
If it was decided to follow this r= oute, the captures could provide a label to correlate to the media in the a= bove structure. This structure would effectively mirror what is in a CLUE A= dvertisement (Its not clear what the benefit would be for duplicating the i= nformation). The complicating factor is that the conference focus (MCU) may= CLUE Advertise different captures than what was originally advertised from= the source Endpoints. i.e. the MCU may compose/switch streams. Therefore t= he information about the captures from the Endpoint (i.e. role) may be diff= erent from what is received by a Consumer in an Advertisement. This would b= e problematic for a Consumer to try to correlate the information from the C= onference Event Package to what it actually receives in the CLUE Advertisem= ent for the purpose Capture selection based on the role information.
[MB] The reality is= that a CLUE implementation will have to correlate some of this information= , but those are implementation details that we can provide guidance on but = would be non-normative. =A0Call Flows are a really good place to illustrate= this sort of thing. [/MB]

A further complication is the relationship between the CLUE messages and an= y SIP subscribes/Notifies related to the Capture Scene /Capture / Role info= rmation. There would be race conditions regarding when the Conference Packa= ge data is received vs when an CLUE Advertisement is received vs the recept= ion of updated SDP Offer/Answers. This co-ordination would be non-trivial.<= span style=3D"color:rgb(34,34,34)">=A0

To avoid this situation it's appropriate to provide information regardi= ng captures (including the role information) in the CLUE messages as it rel= ates to the people in the captures and removes any interaction issues.
[MB] If we do that,= you then need to explain the relationship between this information and rol= e information in the event package and still ensure that it's consisten= t. =A0Again, CLUE is based on SIP/SIP conferencing. =A0We must ensure that = there's consistency in information. So, your proposal moves the problem= around and adds unnecessary complexity to CLUE that isn't required for= fundamental multi-stream processing. =A0It's certainly useful informat= ion for the application, but not fundamental to CLUE deliverables (just as = rosters are out of scope). [/MB]

It also must be remembered that the Capture attributes are intended for pro= cessing by automata and/or humans. The focus of the Conference Event framew= ork is purely with respect to endpoint and media information as per RFC4575= Sect 5.1 is "...<endpoint>, and <media> are intended for = display to human subscribers only".
[MB] =A0And, I think that= 's actually an error in RFC 4575. =A0If you read further, it notes that= =A0<media> is used to [/MB]=A0
The intent of the "role" information in CL= UE is to allow for processing by automata. RFC4575 Section 5.6.3 there is n= o definition of what this is other than a set of strings. Its only for huma= n consumption. RFC6501 section 4.6.5.2 does provide some values for "r= ole" but these do not cover vCard type information nor the full set of= conference roles.
[MB] Certainly, but it co= uld be extended to include such. Personally, I don't think this is cruc= ial to the CLUE deliverables at this point. =A0We could certainly do extens= ions later, once we get the basic CLUE stuff done (which I believe (putting= on my chair hat) is a much higher priority than adding this element) [/MB]= =A0
Also given the scope issue raised a= bove it wouldn't be possible to indicate the people within the capture.=

Furthermore CLUE is meant for use in point to point and multi-point environ= ments. So far it has been designed to be largely independent from other pro= tocols. i.e. its not coupled to BUNDLE and the encoding information is sepa= rate.
[MB] It's not directl= y coupled, but CLUE is coupled with SDP based upon the decision to include = the encoding limits in SDP. =A0[/MB]=A0
The conference framework may or may not be used depe= nding on the call or network scenario. Therefore it doesn't seem wise t= o place capture attribute information such as "role" information = only in the Conference Event Package. This would mean that the role informa= tion could only be used in a limited sub-set of scenarios.
[MB] That is certai= nly a valid point, but I still contend that this is not something that is N= OT specific to CLUE or multi-stream in general. =A0Also, as I've said b= efore, this issue has been raised generally in DISPATCH: http://www.ie= tf.org/mail-archive/web/dispatch/current/msg04805.html =A0 =A0Now, if t= his were something fundamental to CLUE, then I would fully agree that solvi= ng the problem just for CLUE is the right thing to do, but it's not, so= I think working on something more general and then later extending CLUE is= a much better option at this juncture. =A0[/MB]=A0

Therefore I believe its appropriate to add role in CLUE at this time.

Comments?

Regards, Christian

_______________________________________________
clue mailing list
clue@ietf.or= g <mailto:clue@ie= tf.org>
ht= tps://www.ietf.org/mailman/listinfo/clue


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


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






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

--f46d043892b192f0d604edbd0614-- From internet-drafts@ietf.org Thu Dec 19 15:10:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD521AEBF5; Thu, 19 Dec 2013 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUYKBAK9XTxq; Thu, 19 Dec 2013 15:10:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4181AE269; Thu, 19 Dec 2013 15:10:27 -0800 (PST) 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.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219231027.6967.30588.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 15:10:27 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 23:10:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-13.txt Pages : 66 Date : 2013-12-19 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-13 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 Mark.Duckworth@polycom.com Thu Dec 19 15:17:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A081AD9B6 for ; Thu, 19 Dec 2013 15:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTQ-WE69u_N1 for ; Thu, 19 Dec 2013 15:17:34 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7C51AD66E for ; Thu, 19 Dec 2013 15:17:34 -0800 (PST) Received: from CRPMBOXPRD07.polycom.com ([fe80::8113:9ad1:f9be:53f1]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 19 Dec 2013 15:17:32 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 19 Dec 2013 15:17:31 -0800 Thread-Topic: [clue] I-D Action: draft-ietf-clue-framework-13.txt Thread-Index: Ac79D4WqRF5JVxtMTXePrj2BrIUD0QAACfGA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D6029DE4B354@CRPMBOXPRD07.polycom.com> References: <20131219231027.6967.30588.idtracker@ietfa.amsl.com> In-Reply-To: <20131219231027.6967.30588.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 23:17:36 -0000 The main purpose of this version is to add the Multiple Content Capture mec= hanism, based on draft-groves-clue-multi-content-00, and discussions on the= list and at IETF88. I have comments on a few topics about MCC I will bring to the list in the n= ext few days. Changes from 12 to 13: 1. Added the MCC concept including updates to existing sections to incorporate the MCC concept. New MCC attributes: MaxCaptures, SynchronisationID and Policy. 2. Removed the "composed" and "switched" Capture attributes due to overlap with the MCC concept. 3. Removed the "Scene-switch-policy" CSE attribute, replaced by MCC and SynchronisationID. 4. Editorial enhancements including numbering of the Capture attribute sections, tables, figures etc. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, December 19, 2013 6:10 PM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-framework-13.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the ControLling mUltiple streams for tElepr= esence > Working Group of the IETF. >=20 > Title : Framework for Telepresence Multi-Streams > Author(s) : Mark Duckworth > Andrew Pepperell > Stephan Wenger > Filename : draft-ietf-clue-framework-13.txt > Pages : 66 > Date : 2013-12-19 >=20 > Abstract: > This document defines a framework for a protocol to enable devices > in a telepresence conference to interoperate. The protocol enables > communication of information about multiple media streams so a > sending system and receiving system can make reasonable decisions > about transmitting, selecting and rendering the media streams. > This protocol is used in addition to SIP signaling for setting up a > telepresence session. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-framework-13 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-13 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Dec 20 15:38:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC991ACCDC for ; Fri, 20 Dec 2013 15:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.989 X-Spam-Level: X-Spam-Status: No, score=-3.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP7UrX92wEpM for ; Fri, 20 Dec 2013 15:38:32 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 403341AC4C1 for ; Fri, 20 Dec 2013 15:38:32 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id z2so9069615wiv.7 for ; Fri, 20 Dec 2013 15:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lmq5/VVp+mbwHV34Fib7APtg6vBwZoDIvyUVG+xln7o=; b=gcVfO6MnUgKVDdjHhl4IuRvh3147v6xmDVIOapTLeNW8cpvO3Rnggu5WrM/Sa0EN5j bHRyBYMU2dvHsrGJYBJU1/17//YEVLa8HSgo6dYz0bjQYysmlpxLzvbxZvzJ7FusEc0a exQ6RdNh2Rf2J9/xLUmJlS2cO+n5IfidtURs36BoZdnIIC76fK+x1GMcmAYznRNHLQFQ t7DK04IzdqLHK59zzULQ+xSjoJle82r2bGVvC79e5mxXa+uR+zR9Ok8WEENtH0nlHKOc cg+847I9flqIhnjwp6DLxsPj/sV9PSRCrUjEgxhaMWxBQPF3CCNDUAoFcA/BnIVSdu8t gY5w== MIME-Version: 1.0 X-Received: by 10.194.241.228 with SMTP id wl4mr9340191wjc.2.1387582709321; Fri, 20 Dec 2013 15:38:29 -0800 (PST) Received: by 10.216.172.9 with HTTP; Fri, 20 Dec 2013 15:38:29 -0800 (PST) Date: Fri, 20 Dec 2013 17:38:29 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e01493c327c549604edffc6ed Cc: "rai-ads@tools.ietf.org" Subject: [clue] Meeting invitation: CLUE WG Virtual Interim - January 27, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 23:38:34 -0000 --089e01493c327c549604edffc6ed Content-Type: text/plain; charset=ISO-8859-1 Hi all, Per the doodle, this is the optimal date/time for the virtual interim meeting. A preliminary agenda is on the wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki/interim140127 Topic: CLUE WG Virtual Interim Date: Monday, January 27, 2014 Time: 9:00 am, Central Standard Time (Chicago, GMT-06:00) Meeting Number: 649 213 018 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=258665132&UID=0&PW=NNWY0OWU0ZTA3&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=258665132&UID=0&PW=NNWY0OWU0ZTA3&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:649 213 018 ------------------------------------------------------- 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=258665132&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAvu-LBkNqSI3NezykeluTZAmhDaGBnogd6RIIn9DQYR8&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:+16504793208x649213018# 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. --089e01493c327c549604edffc6ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Per the doodle,= this is the optimal date/time for the virtual interim meeting. =A0A prelim= inary agenda is on the wiki:
http://trac.tools.ietf.org= /wg/clue/trac/wiki/interim140127

Topic: CLUE WG Virtual I= nterim
Date: Monday, January 27, 2014
Time: 9:00 am, Central Stan= dard Time (Chicago, GMT-06:00)
Meeting Number: 649 213 018
Meeting Password: 1234


---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to https://ietf= .webex.com/ietf/j.php?ED=3D258665132&UID=3D0&PW=3DNNWY0OWU0ZTA3&= ;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://ietf.webex.c= om/ietf/j.php?ED=3D258665132&UID=3D0&PW=3DNNWY0OWU0ZTA3&ORT=3DM= iM3

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

Access code:649 213 018

-----------------------------------= --------------------
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:
https://ietf.= webex.com/ietf/j.php?ED=3D258665132&UID=3D0&ICS=3DMI&LD=3D1&= ;RD=3D2&ST=3D1&SHA2=3DAAAAAvu-LBkNqSI3NezykeluTZAmhDaGBnogd6RIIn9DQ= YR8&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:+16504793208x649213018#

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.

--089e01493c327c549604edffc6ed-- From Christian.Groves@nteczone.com Sun Dec 22 20:32:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06B91AC49D for ; Sun, 22 Dec 2013 20:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eES_shY-b8a7 for ; Sun, 22 Dec 2013 20:32:20 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1531AED1D for ; Sun, 22 Dec 2013 20:32:20 -0800 (PST) Received: from ppp118-209-201-245.lns20.mel6.internode.on.net ([118.209.201.245]:56568 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1VuxBF-0003qT-Hk for clue@ietf.org; Mon, 23 Dec 2013 15:31:49 +1100 Message-ID: <52B7BCCE.1040409@nteczone.com> Date: Mon, 23 Dec 2013 15:32:14 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Subject: [clue] Design team meeting on roles followup X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 04:32:22 -0000 Hello One of the items that came up at the design team meeting on roles was to avoid the use of the term "role" and the confusion that it brings with respect to conference control. In order to address this I propose the following terms: Participant Information: this is equivalent to vCard(xCard) information that would be set against an individual Capture. Scene Information: This is equivalent to vCard(xCard) information that would be set against a Capture Scene. Participant Type: This is equivalent to what was proposed as "meeting role" in the role draft. i.e. Chairman, Vice-Chairman, Secretary, Participant, Presenter, Translator, Timekeeper and a possibility for further provider defined types. Any issues with the above terms? Note: I'm only discussing the terms. I'll provide some proposals to add these to the framework once we can find terms people are happy with. Regards, Christian From mary.ietf.barnes@gmail.com Mon Dec 23 13:54:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732FC1AE239 for ; Mon, 23 Dec 2013 13:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Y5RgPRLVw00 for ; Mon, 23 Dec 2013 13:54:08 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id E7C861AE2D0 for ; Mon, 23 Dec 2013 13:54:07 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so5471638wgh.9 for ; Mon, 23 Dec 2013 13:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=kUVKDidgkM8155QBKInZ31rMSGrZnkHDUQW97+oiUR4=; b=ZkIqU3ZsXXuTHBNPMymGsvoI0SGBL7I7eS5w56QtGsMwsPueXZWVDbmVyemr2P/0jb kXBbtyfMAgO7yq64PhyQgGZxDvIrhR7oNGEkNxtRiNYbaKGj+gn9onxpVh2229vpWe8S aPPC8Bx7t0yjBRGUQr8e+1IkGXh6mpEsTC5SsSEFiwNMmDveXz7XEg+pdW1zYjfsHAm0 +mNBG/AG2NQoUkWcZkkgbV/QNcWpfOBMCGKmdl1uKvbYuYuNtakYGBm2i297PRSo39u/ Z+pwGELdV51kWmfS37yfPJlmj7Ubd5+vb2DUE8ne72X0Xd3t048dJw4poyfA/PPt+8Rt GG/Q== MIME-Version: 1.0 X-Received: by 10.194.161.233 with SMTP id xv9mr1812971wjb.79.1387835644079; Mon, 23 Dec 2013 13:54:04 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 23 Dec 2013 13:54:04 -0800 (PST) Date: Mon, 23 Dec 2013 15:54:04 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e013d1f9e9274c404ee3aaa53 Subject: [clue] IPR on CLUE Framework, Signaling and protocol documents X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 21:54:09 -0000 --089e013d1f9e9274c404ee3aaa53 Content-Type: text/plain; charset=ISO-8859-1 HI all, For some reason, some recent IPR disclosures did not generate the auto-email notifying the WG and the authors. Please look at the IPR related to: draft-ietf-clue-framework draft-kyzivat-clue-signaling draft-presta-clue-protocol Note, I have sent an email to ietf-action to figure out why the emails weren't generated since it looks like the tool has properly captured the IPR disclosures. Regards Mary as CLUE WG co-chair --089e013d1f9e9274c404ee3aaa53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

For some reason, some recent IP= R disclosures did not generate the auto-email notifying the WG and the auth= ors. =A0

Please look at the IPR related to:
<= div>
draft-presta-clue-protocol

Note, I have sent an email to ietf-action to figure= out why the emails weren't generated since it looks like the tool has = properly captured the IPR disclosures.=A0

Regards
Mary
as CLUE WG co-chair
--089e013d1f9e9274c404ee3aaa53-- From mary.ietf.barnes@gmail.com Mon Dec 23 14:16:18 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E701AE2F6 for ; Mon, 23 Dec 2013 14:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYrJW5b7ENyn for ; Mon, 23 Dec 2013 14:16:15 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9E41AE2F4 for ; Mon, 23 Dec 2013 14:16:15 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so6716542wib.4 for ; Mon, 23 Dec 2013 14:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=K+lE6Lgr0Z619jV7GCP3uQQk39SbOZe2sdyEq4ygIeY=; b=V5JppNxJXP9pWhMQR/CBYM7mvk1mlFNt1kdNv6CejcDWdbwZcQG3LMITacC1OQh6IX mFQheXFt8Z7GxVckFLBFnjqrvGlK7hIODr9/IzaSIVZy0VjwT+E3CuCUfMB7+Dfnjc+u THj/aFEDmRus+LDs46pj6FPfQwEXO5yOfpZW3tM9iq+w8VH5UFVl8yTrVbQ7kqDoyYca p6X9Md7/xQM/+hZkHSDARVW+qj41Hqx58L7oasWGNmeMN3CWT72eLVB55uHYU3utLaIK SoSvGTlscEVaERY53qxYUPZ3vDE5Uz205J8mi/FcA334SNLEywgh4MGiuOL1sKoQBEo3 cxjQ== MIME-Version: 1.0 X-Received: by 10.180.184.105 with SMTP id et9mr16729106wic.36.1387836971574; Mon, 23 Dec 2013 14:16:11 -0800 (PST) Received: by 10.216.172.9 with HTTP; Mon, 23 Dec 2013 14:16:11 -0800 (PST) Date: Mon, 23 Dec 2013 16:16:11 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c228a2b2692504ee3af95e Subject: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May 2014. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 22:16:18 -0000 --001a11c228a2b2692504ee3af95e Content-Type: text/plain; charset=ISO-8859-1 Hi all, As mentioned at IETF-88 and on the mailing list, we are considering a face-to-face interim meeting in the mid-late May timeframe. The University of Naples has graciously volunteered to host the meeting. I have setup a doodle to find an optimal time for CLUE WG contributors and participants. There are some potential conflicts and there likely is no perfect date for everyone. The poll is Yes-No-maybe, so please put 'No' only if it's absolutely impossible for you to attend on that day. There is a US holiday the Monday (May 26) of the last week of May and there is a 3GPP meeting (May 19-23) and IMTC SuperOp (May 16-24) the week prior. There is also a rumor of a potential RTCWEB (and MMUSIC) interims around that same timeframe. In the past it hasn't been particularly valuable to CLUE to try to co-locate as all the meetings don't fit in a single week AND we have not gotten additional RTCWEB folks to attend the CLUE meeting when they have been co-located. http://doodle.com/5c7rb9ac6e2tnwfk In order to allow folks to plan for the meeting, I suggest we close the doodle on January 31st, 2014. Thanks, Mary. --001a11c228a2b2692504ee3af95e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

As mentioned at IETF-88 and o= n the mailing list, we are considering a face-to-face interim meeting in th= e mid-late May timeframe. The University of Naples has graciously volunteer= ed to host the meeting.=A0

I have setu= p a doodle to find an optimal time for CLUE WG contributors and participant= s. =A0There are some potential conflicts and there likely is no perfect dat= e for everyone. =A0The poll is Yes-No-maybe, so please put 'No' onl= y if it's absolutely impossible for you to attend on that day. =A0There= is a US holiday the Monday (May 26) of the last week of May and there is a= 3GPP meeting =A0(May 19-23) =A0and=A0IMTC SuperOp (May 16-24) the week pri= or. =A0 There is also a rumor of a potential RTCWEB (and MMUSIC) interims a= round that same timeframe. =A0In the past it hasn't been particularly v= aluable to CLUE to try to co-locate as all the meetings don't fit in a = single week AND we have not gotten additional RTCWEB folks to attend the CL= UE meeting when they have been co-located. =A0 =A0

http:/= /doodle.com/5c7rb9ac6e2tnwfk

In order to allow folks to plan for th= e meeting, I suggest we close the doodle on January 31st, 2014. =A0=A0

Thanks,
Mary.=A0

--001a11c228a2b2692504ee3af95e-- From ron.even.tlv@gmail.com Tue Dec 24 00:15:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0BE1AD8DB for ; Tue, 24 Dec 2013 00:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 595nsyTpkos6 for ; Tue, 24 Dec 2013 00:15:56 -0800 (PST) Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id BC74F1ACCDF for ; Tue, 24 Dec 2013 00:15:55 -0800 (PST) Received: by mail-ea0-f169.google.com with SMTP id l9so2377792eaj.28 for ; Tue, 24 Dec 2013 00:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=vHMABkwp3YRi8YsGhtBPvl7R7I/dJEhO1lsr9bx3xJs=; b=Md6Onyage+AFEKqzfw+YjvDWL+I0olez/A5VCZI939Q17ZK//zgxDdcapEZA01giHr cMrGz4O/uU9Ip8t1Oxi2gv2VFSpZjtZDWQmVz+ZDwoXmbE7T0510wB502IiT29fH2YhY oM0VUYp1f3gjZqTpRDS82GTUONJgnk+L4+849XR/hNDm/x4XCUDt8kAYQ+vya2tEg34r 94QyeRWkP4n8TBX9HjITmHMEuyykTkou709Y+2R+BaOr9iYOQsMXni7fns2h2K7lqfd/ v9et1mT3LPTW4eFnni8qna41a0jFHh9hc0XdRgpqSA9dAx5pBrBuC/lgT+kkIgTmMJzy Ko2g== X-Received: by 10.14.32.132 with SMTP id o4mr26681103eea.14.1387872916867; Tue, 24 Dec 2013 00:15:16 -0800 (PST) Received: from RoniE ([109.64.17.204]) by mx.google.com with ESMTPSA id m1sm52740619eeg.0.2013.12.24.00.15.14 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Dec 2013 00:15:16 -0800 (PST) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 24 Dec 2013 10:11:40 +0200 Message-ID: <081d01cf007f$c80f5b90$582e12b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_081E_01CF0090.8B98C7D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLsNHbX8YtkdHgN5fYmXskiMDzp8ZgoloUw Content-Language: en-us Subject: Re: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May 2014. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 08:15:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_081E_01CF0090.8B98C7D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mary, Is the f2f meeting one day? Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 24 December, 2013 12:16 AM To: CLUE Subject: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May 2014. Hi all, As mentioned at IETF-88 and on the mailing list, we are considering a face-to-face interim meeting in the mid-late May timeframe. The University of Naples has graciously volunteered to host the meeting. I have setup a doodle to find an optimal time for CLUE WG contributors and participants. There are some potential conflicts and there likely is no perfect date for everyone. The poll is Yes-No-maybe, so please put 'No' only if it's absolutely impossible for you to attend on that day. There is a US holiday the Monday (May 26) of the last week of May and there is a 3GPP meeting (May 19-23) and IMTC SuperOp (May 16-24) the week prior. There is also a rumor of a potential RTCWEB (and MMUSIC) interims around that same timeframe. In the past it hasn't been particularly valuable to CLUE to try to co-locate as all the meetings don't fit in a single week AND we have not gotten additional RTCWEB folks to attend the CLUE meeting when they have been co-located. http://doodle.com/5c7rb9ac6e2tnwfk In order to allow folks to plan for the meeting, I suggest we close the doodle on January 31st, 2014. Thanks, Mary. ------=_NextPart_000_081E_01CF0090.8B98C7D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

Is the f2f meeting one day?

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 24 December, 2013 12:16 AM
To: = CLUE
Subject: [clue] Doodle: Link for poll "CLUE WG f2f = Interim meeting" May 2014.

 

Hi = all,

 

As mentioned at IETF-88 and on the mailing list, we = are considering a face-to-face interim meeting in the mid-late May = timeframe. The University of Naples has graciously volunteered to host = the meeting. 

 

I have setup a doodle to find an optimal = time for CLUE WG contributors and participants.  There are some = potential conflicts and there likely is no perfect date for everyone. =  The poll is Yes-No-maybe, so please put 'No' only if it's = absolutely impossible for you to attend on that day.  There is a US = holiday the Monday (May 26) of the last week of May and there is a 3GPP = meeting  (May 19-23)  and IMTC SuperOp (May 16-24) the = week prior.   There is also a rumor of a potential RTCWEB (and = MMUSIC) interims around that same timeframe.  In the past it hasn't = been particularly valuable to CLUE to try to co-locate as all the = meetings don't fit in a single week AND we have not gotten additional = RTCWEB folks to attend the CLUE meeting when they have been co-located. =    

http://doodle.com/5c7rb9ac6e2tnwfk

In order to allow folks to plan for the = meeting, I suggest we close the doodle on January 31st, 2014. =   

 

Thanks,

Mary. 

 

------=_NextPart_000_081E_01CF0090.8B98C7D0-- From mary.ietf.barnes@gmail.com Tue Dec 24 07:33:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925011ADFB3 for ; Tue, 24 Dec 2013 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrdL_vmiwm29 for ; Tue, 24 Dec 2013 07:33:05 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9D1ADF68 for ; Tue, 24 Dec 2013 07:33:05 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so6127750wes.12 for ; Tue, 24 Dec 2013 07:33:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+u2TC4q3DLNKNPaqbIcSFUHDigYLmkdDS93lq0iN3tc=; b=y9/ns/4if56/1CHt8CCyktJRLY88Hn5X7GRYa2g2kNf/a+FmsE+2qWfutFqbhgd4q0 PyZg/vJ0By4fYXWGQgLl+y++5tixxa2vWCXy+ud7BGbyM4HKXGTFDUtJ3qpFlBJeuldH 4AtEZvTcdmeZbhd3NwZvu9/cn/gArJGdUeSPJPUOGnQJ0J5w4bRewpSyP6pmPfuznbPS BDz/0OTfTN/Od8QPr92p2mMnTj9P1MgaqHph33PuHhEq0QOt40uFnmHapKZAzoXtGs5W CGYqVCgiCNF8u5a3W/v7TqllWaBvjb5AeTHax2XQsQS+YjgACph7wpe6Gru0Vh/CqZr6 Wheg== MIME-Version: 1.0 X-Received: by 10.180.93.8 with SMTP id cq8mr23760834wib.38.1387899181475; Tue, 24 Dec 2013 07:33:01 -0800 (PST) Received: by 10.216.172.9 with HTTP; Tue, 24 Dec 2013 07:33:01 -0800 (PST) In-Reply-To: <081d01cf007f$c80f5b90$582e12b0$@gmail.com> References: <081d01cf007f$c80f5b90$582e12b0$@gmail.com> Date: Tue, 24 Dec 2013 09:33:01 -0600 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d043892b1b22dce04ee4975d7 Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May 2014. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 15:33:08 -0000 --f46d043892b1b22dce04ee4975d7 Content-Type: text/plain; charset=ISO-8859-1 Sorry. I should have made it clear. The intention would be a two day meeting. Mary. On Tue, Dec 24, 2013 at 2:11 AM, Roni Even wrote: > Hi Mary, > > Is the f2f meeting one day? > > Roni > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 24 December, 2013 12:16 AM > *To:* CLUE > *Subject:* [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May > 2014. > > > > Hi all, > > > > As mentioned at IETF-88 and on the mailing list, we are considering a > face-to-face interim meeting in the mid-late May timeframe. The University > of Naples has graciously volunteered to host the meeting. > > > > I have setup a doodle to find an optimal time for CLUE WG contributors and > participants. There are some potential conflicts and there likely is no > perfect date for everyone. The poll is Yes-No-maybe, so please put 'No' > only if it's absolutely impossible for you to attend on that day. There is > a US holiday the Monday (May 26) of the last week of May and there is a > 3GPP meeting (May 19-23) and IMTC SuperOp (May 16-24) the week prior. > There is also a rumor of a potential RTCWEB (and MMUSIC) interims around > that same timeframe. In the past it hasn't been particularly valuable to > CLUE to try to co-locate as all the meetings don't fit in a single week AND > we have not gotten additional RTCWEB folks to attend the CLUE meeting when > they have been co-located. > > http://doodle.com/5c7rb9ac6e2tnwfk > > In order to allow folks to plan for the meeting, I suggest we close the > doodle on January 31st, 2014. > > > > Thanks, > > Mary. > > > --f46d043892b1b22dce04ee4975d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sorry. I should have made it clear. The intention would be= a two day meeting.=A0

Mary.=A0


On Tue, Dec 24, 2013 at 2:= 11 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Mary,

Is the f2f meeting one da= y?

=A0<= /p>

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 24 December, 2013 12:16 AM
To: CLUE
Subject: [clue] Doodle: Link for poll "CLUE WG f2f Interim meeting" May= 2014.

=A0

Hi all,=

=A0

As mentioned at IETF-88 and on the mailing list, we are c= onsidering a face-to-face interim meeting in the mid-late May timeframe. Th= e University of Naples has graciously volunteered to host the meeting.=A0

=A0

I have setup a doodle to find= an optimal time for CLUE WG contributors and participants. =A0There are so= me potential conflicts and there likely is no perfect date for everyone. = =A0The poll is Yes-No-maybe, so please put 'No' only if it's ab= solutely impossible for you to attend on that day. =A0There is a US holiday= the Monday (May 26) of the last week of May and there is a 3GPP meeting = =A0(May 19-23) =A0and=A0IMTC SuperOp (May 16-24) the week prior. =A0 There = is also a rumor of a potential RTCWEB (and MMUSIC) interims around that sam= e timeframe. =A0In the past it hasn't been particularly valuable to CLU= E to try to co-locate as all the meetings don't fit in a single week AN= D we have not gotten additional RTCWEB folks to attend the CLUE meeting whe= n they have been co-located. =A0 =A0

http:/= /doodle.com/5c7rb9ac6e2tnwfk

In order to allow folks to plan for the meeting, I suggest we clos= e the doodle on January 31st, 2014. =A0=A0

=A0

Thanks,

M= ary.=A0

=A0


--f46d043892b1b22dce04ee4975d7--