From nobody Mon Jan 5 10:05:44 2015 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 965B91A871D for ; Mon, 5 Jan 2015 10:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X5ML0Q0Oepv for ; Mon, 5 Jan 2015 10:05:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D611A6F3A for ; Mon, 5 Jan 2015 10:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7126; q=dns/txt; s=iport; t=1420481141; x=1421690741; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=yy+70ECyC7YR+OOe7sic92Po+Kx91VaP8R0WCnd3pGk=; b=foUtRCDLdltEHZA4egeJMEKerUnyBJECmkC002Z3JTsVxtru5IT8dZnB QeMejzINGeXUIH4wlWlRYbXe/WEd8yPy9O4+kxr/GX2iK86W97HWI8OPN GZlmMB7JYDfNc02FSjBCGcIT2bkNxdWI7JXUs1d+003FXYXvsZNt0J8TN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMHACrSqlStJssW/2dsb2JhbABcgkOBFVizWgEBAQEBAQUBd5E5AQmFcwKBHwEBAQEBfYQNAQEEAQEBKkEKEQsYCRYPCQMCAQIBFTATBgIBAYgoDbxmAQEBAQEBAQMBAQEBAQEBFwSGA4l7hCkFlwiGBItMIoNuPjGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,701,1413244800"; d="scan'208,217";a="300161498" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 05 Jan 2015 18:05:32 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t05I5VFH011272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 5 Jan 2015 18:05:31 GMT Message-ID: <54AAD26C.5020602@cisco.com> Date: Mon, 05 Jan 2015 18:05:32 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9@CRPMBOXPRD08.polycom.com> Content-Type: multipart/alternative; boundary="------------020101050606020205010807" X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/14Qav5MAg65WFxg1KY7uT2Wbms4 Subject: Re: [clue] example of CLUE exchange without SDP offer/answer 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, 05 Jan 2015 18:05:43 -0000 This is a multi-part message in MIME format. --------------020101050606020205010807 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I think that's a good change, as that's a change at the CLUE level people will want to make that shouldn't prompt an SDP change. Rob On 22/12/14 15:20, Duckworth, Mark wrote: > > Comment from Rob about this passage in framework section 5: > > “During the lifetime of a call, further exchanges MAY occur over the > CLUE channel. In some cases, those further exchanges lead to a > modified system behavior of Provider or Consumer (or both) without any > other protocol activity such as further offer/answer exchanges. For > example, voice-activated screen switching, signaled over the CLUE > channel, ought not to lead to heavy-handed mechanisms like SIP > re-invites.” > > From Rob’s WGLC comments: > > >Section 5. page 13: > > >"For example, voice-activated screen switching, signaled over the > CLUE channel, ought not to" > > >- was a bit confused by this; does this mean an MCC noted as > voice-switched, or actually > > >somehow signalling which participant is currentl the active speaker > via CLUE (and if the latter, > > >how do we do that)? My guess is that this relates to behaviour that > is now available at the RTP > > >level instead. > > This is intended to be an example of something that could be done > using CLUE signaling, which then affects the RTP streams, but does not > require SDP changes. I agree with Rob it is not a good example, > because I can’t think of anything about “voice activated screen > switching” that fits this scenario. > > I suggest replacing this with a different example. Proposed new text: > > “For example, a Configure Message requesting the Provider to place a > different Capture source into a Capture Encoding, signaled over the > CLUE channel, ought not to ...” > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------020101050606020205010807 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I think that's a good change, as that's a change at the CLUE level people will want to make that shouldn't prompt an SDP change.

Rob

On 22/12/14 15:20, Duckworth, Mark wrote:

Comment from Rob about this passage in framework section 5:

 

“During the lifetime of a call, further exchanges MAY occur over the CLUE channel.  In some cases, those further exchanges lead to a modified system behavior of Provider or Consumer (or both) without any other protocol activity such as further offer/answer exchanges.  For example, voice-activated screen switching, signaled over the CLUE channel, ought not to lead to heavy-handed mechanisms like SIP re-invites.”

 

From Rob’s WGLC comments:

 

>Section 5. page 13:

>"For example, voice-activated screen switching, signaled over the CLUE channel, ought not to"

>- was a bit confused by this; does this mean an MCC noted as voice-switched, or actually

>somehow signalling which participant is currentl the active speaker via CLUE (and if the latter,

>how do we do that)? My guess is that this relates to behaviour that is now available at the RTP

>level instead.

 

This is intended to be an example of something that could be done using CLUE signaling, which then affects the RTP streams, but does not require SDP changes.  I agree with Rob it is not a good example, because I can’t think of anything about “voice activated screen switching” that fits this scenario.

 

I suggest replacing this with a different example.  Proposed new text:

“For example, a Configure Message requesting the Provider to place a different Capture source into a Capture Encoding, signaled over the CLUE channel, ought not to ...”

 

Mark



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

--------------020101050606020205010807-- From nobody Mon Jan 5 10:08:21 2015 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 7A23F1A8724 for ; Mon, 5 Jan 2015 10:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K2s11-QAryc for ; Mon, 5 Jan 2015 10:08:17 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46A31A0371 for ; Mon, 5 Jan 2015 10:08:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3287; q=dns/txt; s=iport; t=1420481297; x=1421690897; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lMS6S7sptMdSoCyg/kZ5qmnwuVENvcHNUoQ+jhXJu1A=; b=H52A+8L9K2Dd8UlpIw25UiGshgZlnmciIDmrvlqkkBeIDqXGfQ9T81R4 7H+KYme0G2vRnyPz+rT8k73pfOumtl5s6mxVVH12uN2B51TXCt3MGAvjP FAaricsPlZOVtcMKjOcNAdbCNeyLuphWceuCYxMiC6fCZzB77IJqgzZ3a 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswHAKvRqlStJssW/2dsb2JhbABchDCzWgEBAQEBAQUBd5c2AoEfAQEBAQF9hAwBAQEEOEANBAsRBAEBAQkWCAcJAwIBAgE0CQgGAQwGAgEBiCi8cQEBAQEBAQEBAQEBAQEBAQEBAQEBAReGA4kSEQFLDAaEIwEElwiBDYR3hAaEDYM5IoNuPjGBAwUEF4EgAQEB X-IronPort-AV: E=Sophos;i="5.07,701,1413244800"; d="scan'208";a="296077407" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Jan 2015 18:08:15 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t05I8EIx006984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Jan 2015 18:08:15 GMT Message-ID: <54AAD30F.1010907@cisco.com> Date: Mon, 05 Jan 2015 18:08:15 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <008f01d017b1$8bb2de70$a3189b50$@gmail.com> <548EBF08.8090900@cisco.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC0@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC0@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/drJQXawXyy6uubol1BfXkVczhdU Subject: Re: [clue] Framework WGLC 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, 05 Jan 2015 18:08:19 -0000 Thanks, Mark. Rob On 22/12/14 21:57, Duckworth, Mark wrote: > Hi Rob, > I implemented most of your suggestions, and started new email threads for a couple of them. > > You had one comment about being more clear the consumer can pick and choose captures regardless of CSVs. I didn't change anything because section 7.3 Capture Scene already says "it can pick and choose Media Captures regardless of how the Provider arranges them in Capture Scene Views." > > I left the multiple encodings in the encoding group example because there are still multiple captures that refer to the same encoding group, so it is still possible to use more than one encoding from a group. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen >> Sent: Monday, December 15, 2014 5:59 AM >> To: clue@ietf.org >> Subject: Re: [clue] Framework WGLC >> >> Find my review attached. >> >> Most of the time the document capitalises terms from the terminology, >> but not always; at first I flagged these up whenever I noticed them but >> I'm sure I missed some and by the end I realised that going through with >> grep and 'find next' was going to be much quicker than correcting based >> on my review anyway so I stopped. >> >> Almost all of the issues are just nits with the language or requests for >> clarifications; I'll repeat the two that I thought were contentious: >> >> Section 7.2. page 22: >> "A MCC MAY contain no references to other Captures to indicate that the >> MCC contains content from multiple sources but no information regarding >> those sources is given." - We don't specify if an MCC containing 1 or >> more defined captures may also contain undefined captures. My personal >> choice would be no - advertised MCCs either contain the defined captures >> and no others, or have no defined captures and contain only undefined >> ones. If there are good reasons that any MCC with defined captures also >> needs to contain potentially undefined ones that's fine too but we >> should spell it out. >> >> Section 10. page 39: >> "The Consumer may or may not choose to receive all the indicated >> captures. Therefore it can choose to receive a sub-set ofCaptures >> indicated by the MCC." - this allowance means that any device that >> provides an MCC and defines the captures it contains is required to >> allow any subset of those captures to be chosen bv the consumer. Often >> the reason the provider is providing an MCC initially is because it >> cannot supply all the captures directly; unless it has the resources to >> provide a unique subset of each capture (eg, switched view or custom >> composition) it will be forced to ot include the contained captures in >> the MCC, removing the value of having an MCC in the first place. >> Depending on the clarification to the question on page 22 (whether an >> MCC with defined captures can also contain undefined captures) the >> consumer may still be receiving captures it hasn't specified. My >> preference would be to remove this degree of freedom on the consumer >> side, or at least make it a suggestion to the provider rather than a >> mandatory restriction. There should also be a space in "ofCaptures". >> >> Rob From nobody Mon Jan 5 10:12:46 2015 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 057781A8731 for ; Mon, 5 Jan 2015 10:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEOl-hhvzAH6 for ; Mon, 5 Jan 2015 10:12:44 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A47A1A872F for ; Mon, 5 Jan 2015 10:12:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2769; q=dns/txt; s=iport; t=1420481563; x=1421691163; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=WWRnvTdZZuXR6tVsAbKzKxdPsqSePg9vtOPeIWzwD/A=; b=RE8Gd2nTfq2xb+aEFKxgLtltANU9gVs592Hgwa+ZT3wIMA2jQi6ypumx KG+eiBHTPxJP3DFwG0GmrzXndSpTOdTJT39cZo9LhOihj0OmnxxYQg9ir 8iWFfeplmC3ZY7bPJTYw4agV/2QVjzCCKijlt8Judft+xBs9xEqC4rMte g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAHABbTqlStJssW/2dsb2JhbABTCYNYWLNaAQEBAQEBBQF3kTkKhXMCgR8BAQEBAX2EDQEBBAEBAS8BBTYKEQsYCRYPCQMCAQIBFTATBgIBAYgoDbxpAQEBAQYBAQEBARkEhgOJEgcKAVcWhBMBBJcIhgSLTCKDbj4xgQMFBBeBIAEBAQ X-IronPort-AV: E=Sophos;i="5.07,701,1413244800"; d="scan'208";a="300814160" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Jan 2015 18:12:40 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t05ICei6003678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 5 Jan 2015 18:12:40 GMT Message-ID: <54AAD418.1010206@cisco.com> Date: Mon, 05 Jan 2015 18:12:40 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <5498820A.6000807@alum.mit.edu> In-Reply-To: <5498820A.6000807@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/pinbwRz4U-bhZwEMGGyl2K8a0_U Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 05 Jan 2015 18:12:46 -0000 I'm also good with the proposed change. Rob On 22/12/14 20:41, Paul Kyzivat wrote: > (As individual) I support the proposed change. > > Thanks, > Paul > > On 12/22/14 12:23 PM, Duckworth, Mark wrote: >> We discussed this at the design team meeting last week. See Rob’s email >> from December 15. The issue is we think the Provider should not be >> required to honor a request in a Configure message to use only specific >> Captures in an MCC. Does the group agree with this proposed change? >> >> Current text in the framework: >> >> - The Consumer may or may not choose to receive all the indicated >> Captures. Therefore it can choose to receive a sub-set of Captures >> indicated by the MCC. >> >> For example if the Consumer receives: >> >> MCC1(VC1,VC2,VC3){attributes} >> >> A Consumer could choose all the Captures within a MCCs however if the >> Consumer determines that it doesn't want VC3 it can return >> MCC1(VC1,VC2). If it wants all the individual Captures then it returns >> only the MCC identity (i.e. MCC1). If the MCC in the advertisement does >> not reference any individual captures, then the Consumer cannot choose >> what is included in the MCC, it is up to the Provider to decide. >> >> Proposed new text in the framework: >> >> - The Consumer may or may not request to receive all the indicated >> Captures. Therefore it can request to receive a sub-set of Captures >> indicated by the MCC. >> >> For example if the Consumer receives an Advertisement with: >> >> MCC1(VC1,VC2,VC3){attributes} >> >> A Consumer could choose all the Captures within the MCC, however if the >> Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2) >> in the Configure message. This is just a suggestion to the Provider. >> The Provider MAY consider this suggestion when deciding which Captures >> to include in the MCC Capture Encoding it sends to the Consumer. If the >> Consumer wants all the individual Captures then it returns only the MCC >> identity (i.e. MCC1). If the MCC in the advertisement does not >> reference any individual captures, then the Consumer cannot choose what >> is included in the MCC, it is up to the Provider to decide. >> >> Another possibility is to add a new MCC attribute in the advertisement, >> so the Provider can indicate whether or not it will accept requests >> asking for only a subset of captures in an MCC. >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 5 15:48:13 2015 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 254191A908C for ; Mon, 5 Jan 2015 15:48:12 -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 EtB-iP2vh7ig for ; Mon, 5 Jan 2015 15:48:10 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BC1C1A908B for ; Mon, 5 Jan 2015 15:48:09 -0800 (PST) Received: from ppp118-209-226-133.lns20.mel8.internode.on.net ([118.209.226.133]:49313 helo=[192.168.1.4]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8HMZ-0007bZ-J0 for clue@ietf.org; Tue, 06 Jan 2015 10:47:07 +1100 Message-ID: <54AB22B2.7060608@nteczone.com> Date: Tue, 06 Jan 2015 10:48:02 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yNR7yo2BHMVK-Irj3FW-kqgv10M Subject: Re: [clue] CLUE framework, section 7.1.1.9, "Languages" 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, 05 Jan 2015 23:48:12 -0000 Hello Stephan, That works for me. That's what I intended when I introduced the parameter in http://www.ietf.org/archive/id/draft-groves-clue-capture-attr-01.txt Regards, Christian On 29/12/2014 1:41 PM, Stephan Wenger wrote: > Hi, > > Mark and I are editing the framework document to address comments. > This is with reference to my review, dated 12/16/2014, and > specifically point 5 therein, reproduced as follows: > > 5. Page 20, Languages: is this coded using a universal language tag? > If yes, should that be mentioned here, with reference? > > The proposal is to indicate that an RFC 5646 language tag is used > here. Is this ok? Is it aligned with the current data model and, if > not, should the data model implement that? > > Proposed language below. Plus a normative reference to RFC 5646, of > course. > > I suggest a deadline of January 9, 2015, but do so without checking > with the chairs—who are of course free to set a different date if they > choose so. > > Thanks, > Stephan > > > 7.1.1.9 Language > > The Language attribute indicates one or more languages used in the > content of the Media Capture. Captures MAY be offered in different > languages in case of multilingual and/or accessible conferences. A > Consumer can use this attribute to differentiate between them and pick > the appropriate one. > > Note that the Language attribute is defined and meaningful both for > audio and video captures. In case of audio captures, the meaning is > obvious. For a video capture, "Language" could, for example, be sign > interpretation or text. > > _The Language attribute is coded per [RFC5646]._ > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 5 15:55:33 2015 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 140E71A9072 for ; Mon, 5 Jan 2015 15:55:32 -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 ej7K87b3cJLl for ; Mon, 5 Jan 2015 15:55:30 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0261D1A8884 for ; Mon, 5 Jan 2015 15:55:30 -0800 (PST) Received: from ppp118-209-226-133.lns20.mel8.internode.on.net ([118.209.226.133]:49343 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8HTh-0000N0-Sw for clue@ietf.org; Tue, 06 Jan 2015 10:54:30 +1100 Message-ID: <54AB246C.3030204@nteczone.com> Date: Tue, 06 Jan 2015 10:55:24 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> In-Reply-To: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/145xOlxa2B1SQMAeerUlJDuUVgg Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 05 Jan 2015 23:55:32 -0000 Hello, What it is the practical result of the second "must", i.e. "and the participants in the sessions MUST be made aware of this."? Does this mean there's a legal disclaimer on the window saying that the participants may not be those you expect? Do we need the second part of the sentence pertaining to notification if we say that CLUE information MUST not be used for authorization? Regards, Christian On 29/12/2014 10:03 PM, Roni Even wrote: > > Hi, > > OK with this change > > Roni Even > > As individual > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger > *Sent:* 29 December, 2014 4:52 AM > *To:* CLUE > *Subject:* [clue] CLUE framework, security consideration section, > level of mandation > > Hi, > > Mark and I are editing the framework document to address comments. > > This is with reference to my review, dated 12/16/2014, and > specifically point 9 therein, reproduced as follows: > > 9. Page 70, first paragraphs. There are two unqualified “SHOULD” > statements. In the spirit of fast doc approval, I wouldn’t object if > those were changed to “MUST”. I don’t recall that we discussed these > points before, but I could easily have missed that discussion. > > Unless someone objects the two SHOULD statements will be replaced with > MUST. The modified paragraph in markup is shown below (also > addressing comment 8 of my review, but that’s an editorial change and > should be uncontroversial). Sorry for the messy formatting. > > I suggest a deadline of January 9, 2015, but do so without checking > with the chairs—who are of course free to set a different date if they > choose so. > > Regards, > > Stephan > > A separate data channel is established to transport the CLUE > protocol messages. The contents of the CLUE protocol messages are > based on information introduced in this document, which is > represented by an XML schema for this information defined in the > CLUE data model [ref]._The CLUE data model [I-D.ietf-clue-data-model-schema] defines through an XML schema the syntax to be used._ Some of the information which could possibly introduce privacy concerns is the xCard information as described in section 7.1.1.11. In addition, the (text) > description field in the Media Capture attribute (section 7.1.1.7) > could possibly reveal sensitive information or specific > identities. The same would be true for the descriptions in the > Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) > attributes. One other important consideration for the > information in the xCard as well as the description field in the > Media Capture and Capture Scene View attributes is that while the > endpoints involved in the session have been authenticated, there > is no assurance that the information in the xCard or description > fields is authentic. Thus, this informationSHOULD _MUST_ not be used to > make any authorization decisions and the participants in the > sessionsSHOULD _MUST_ be made aware of this. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 5 16:00:14 2015 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 B3BB31A8F35 for ; Mon, 5 Jan 2015 16:00:12 -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 MomrSU1kJffB for ; Mon, 5 Jan 2015 16:00:10 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6F61A8884 for ; Mon, 5 Jan 2015 16:00:10 -0800 (PST) Received: from ppp118-209-226-133.lns20.mel8.internode.on.net ([118.209.226.133]:49365 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8HYE-00018X-Jl for clue@ietf.org; Tue, 06 Jan 2015 10:59:10 +1100 Message-ID: <54AB2585.8050000@nteczone.com> Date: Tue, 06 Jan 2015 11:00:05 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9@CRPMBOXPRD08.polycom.com> <54AAD26C.5020602@cisco.com> In-Reply-To: <54AAD26C.5020602@cisco.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sYfwWJrpRcqyiVWyt1UWpqpcPS4 Subject: Re: [clue] example of CLUE exchange without SDP offer/answer 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, 06 Jan 2015 00:00:12 -0000 Sounds good to me. Christian On 6/01/2015 5:05 AM, Robert Hansen wrote: > I think that's a good change, as that's a change at the CLUE level > people will want to make that shouldn't prompt an SDP change. > > Rob > > On 22/12/14 15:20, Duckworth, Mark wrote: >> >> Comment from Rob about this passage in framework section 5: >> >> “During the lifetime of a call, further exchanges MAY occur over the >> CLUE channel. In some cases, those further exchanges lead to a >> modified system behavior of Provider or Consumer (or both) without >> any other protocol activity such as further offer/answer exchanges. >> For example, voice-activated screen switching, signaled over the CLUE >> channel, ought not to lead to heavy-handed mechanisms like SIP >> re-invites.” >> >> From Rob’s WGLC comments: >> >> >Section 5. page 13: >> >> >"For example, voice-activated screen switching, signaled over the >> CLUE channel, ought not to" >> >> >- was a bit confused by this; does this mean an MCC noted as >> voice-switched, or actually >> >> >somehow signalling which participant is currentl the active speaker >> via CLUE (and if the latter, >> >> >how do we do that)? My guess is that this relates to behaviour that >> is now available at the RTP >> >> >level instead. >> >> This is intended to be an example of something that could be done >> using CLUE signaling, which then affects the RTP streams, but does >> not require SDP changes. I agree with Rob it is not a good example, >> because I can’t think of anything about “voice activated screen >> switching” that fits this scenario. >> >> I suggest replacing this with a different example. Proposed new text: >> >> “For example, a Configure Message requesting the Provider to place a >> different Capture source into a Capture Encoding, signaled over the >> CLUE channel, ought not to ...” >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 5 16:14:46 2015 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 3B97F1A90A1 for ; Mon, 5 Jan 2015 16:14: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 jxk3qpOGAktF for ; Mon, 5 Jan 2015 16:14:43 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6A91A9095 for ; Mon, 5 Jan 2015 16:14:41 -0800 (PST) Received: from ppp118-209-226-133.lns20.mel8.internode.on.net ([118.209.226.133]:49404 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8HmG-0003z6-NP for clue@ietf.org; Tue, 06 Jan 2015 11:13:41 +1100 Message-ID: <54AB28EA.8040409@nteczone.com> Date: Tue, 06 Jan 2015 11:14:34 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mAg60lIYHH6yFbJa9gqnPE7zk9E Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 06 Jan 2015 00:14:45 -0000 Looking from a user perspective I have trouble with this change. If the MP provider receives an MCC and gives the participants a chance to choose the contributing captures then the user will expect to receive their choice. There's no feedback that their choice isn't allowed other than the captures they don't want appear in their media stream. They'll probably try to do the "choose" procedure again figuring that they did something wrong in the first place. So I don't support going from effectively a "MUST" to "a suggestion". I think the suggestion of adding an MCC attribute to indicate that a subset cannot be chosen is a more robust solution. Regards, Christian On 23/12/2014 4:23 AM, Duckworth, Mark wrote: > > We discussed this at the design team meeting last week. See Rob’s > email from December 15. The issue is we think the Provider should not > be required to honor a request in a Configure message to use only > specific Captures in an MCC. Does the group agree with this proposed > change? > > Current text in the framework: > > - The Consumer may or may not choose to receive all the indicated > Captures. Therefore it can choose to receive a sub-set of Captures > indicated by the MCC. > > For example if the Consumer receives: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within a MCCs however if the > Consumer determines that it doesn't want VC3 it can return > MCC1(VC1,VC2). If it wants all the individual Captures then it > returns only the MCC identity (i.e. MCC1). If the MCC in the > advertisement does not reference any individual captures, then the > Consumer cannot choose what is included in the MCC, it is up to the > Provider to decide. > > Proposed new text in the framework: > > - The Consumer may or may not request to receive all the indicated > Captures. Therefore it can request to receive a sub-set of Captures > indicated by the MCC. > > For example if the Consumer receives an Advertisement with: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within the MCC, however if > the Consumer determines that it doesn't want VC3 it can return > MCC1(VC1,VC2) in the Configure message. This is just a suggestion to > the Provider. The Provider MAY consider this suggestion when deciding > which Captures to include in the MCC Capture Encoding it sends to the > Consumer. If the Consumer wants all the individual Captures then it > returns only the MCC identity (i.e. MCC1). If the MCC in the > advertisement does not reference any individual captures, then the > Consumer cannot choose what is included in the MCC, it is up to the > Provider to decide. > > Another possibility is to add a new MCC attribute in the > advertisement, so the Provider can indicate whether or not it will > accept requests asking for only a subset of captures in an MCC. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 5 16:19:26 2015 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 BF9541A90A1 for ; Mon, 5 Jan 2015 16:19:24 -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 B8gpcIZKZ71C for ; Mon, 5 Jan 2015 16:19:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53EE41A9097 for ; Mon, 5 Jan 2015 16:19:22 -0800 (PST) Received: from ppp118-209-226-133.lns20.mel8.internode.on.net ([118.209.226.133]:49595 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8Hqn-0004j9-HW for clue@ietf.org; Tue, 06 Jan 2015 11:18:21 +1100 Message-ID: <54AB2A04.2050807@nteczone.com> Date: Tue, 06 Jan 2015 11:19:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> In-Reply-To: <54AB28EA.8040409@nteczone.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/hmVd_5P5QarqdaRKILOOE4cQF18 Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 06 Jan 2015 00:19:24 -0000 Read MC Media Consumer below. Christian On 6/01/2015 11:14 AM, Christian Groves wrote: > Looking from a user perspective I have trouble with this change. If > the MP provider receives an MCC and gives the participants a chance to > choose the contributing captures then the user will expect to receive > their choice. There's no feedback that their choice isn't allowed > other than the captures they don't want appear in their media stream. > They'll probably try to do the "choose" procedure again figuring that > they did something wrong in the first place. > > So I don't support going from effectively a "MUST" to "a suggestion". > I think the suggestion of adding an MCC attribute to indicate that a > subset cannot be chosen is a more robust solution. > > Regards, Christian > > On 23/12/2014 4:23 AM, Duckworth, Mark wrote: >> >> We discussed this at the design team meeting last week. See Rob’s >> email from December 15. The issue is we think the Provider should >> not be required to honor a request in a Configure message to use only >> specific Captures in an MCC. Does the group agree with this proposed >> change? >> >> Current text in the framework: >> >> - The Consumer may or may not choose to receive all the indicated >> Captures. Therefore it can choose to receive a sub-set of Captures >> indicated by the MCC. >> >> For example if the Consumer receives: >> >> MCC1(VC1,VC2,VC3){attributes} >> >> A Consumer could choose all the Captures within a MCCs however if the >> Consumer determines that it doesn't want VC3 it can return >> MCC1(VC1,VC2). If it wants all the individual Captures then it >> returns only the MCC identity (i.e. MCC1). If the MCC in the >> advertisement does not reference any individual captures, then the >> Consumer cannot choose what is included in the MCC, it is up to the >> Provider to decide. >> >> Proposed new text in the framework: >> >> - The Consumer may or may not request to receive all the indicated >> Captures. Therefore it can request to receive a sub-set of Captures >> indicated by the MCC. >> >> For example if the Consumer receives an Advertisement with: >> >> MCC1(VC1,VC2,VC3){attributes} >> >> A Consumer could choose all the Captures within the MCC, however if >> the Consumer determines that it doesn't want VC3 it can return >> MCC1(VC1,VC2) in the Configure message. This is just a suggestion to >> the Provider. The Provider MAY consider this suggestion when >> deciding which Captures to include in the MCC Capture Encoding it >> sends to the Consumer. If the Consumer wants all the individual >> Captures then it returns only the MCC identity (i.e. MCC1). If the >> MCC in the advertisement does not reference any individual captures, >> then the Consumer cannot choose what is included in the MCC, it is up >> to the Provider to decide. >> >> Another possibility is to add a new MCC attribute in the >> advertisement, so the Provider can indicate whether or not it will >> accept requests asking for only a subset of captures in an MCC. >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Jan 6 08:35:21 2015 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 ABA3D1A0199 for ; Tue, 6 Jan 2015 08:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Kb0z13UQw_T for ; Tue, 6 Jan 2015 08:35:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0107.outbound.protection.outlook.com [65.55.169.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733D41A0275 for ; Tue, 6 Jan 2015 08:35:14 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 16:35:11 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Tue, 6 Jan 2015 16:35:11 +0000 From: Stephan Wenger To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE framework, security consideration section, level of mandation Thread-Index: AQHQKUMbkgW5TlAA8EuhIA6D3OnVKpyyxNGA Date: Tue, 6 Jan 2015 16:35:11 +0000 Message-ID: References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> <54AB246C.3030204@nteczone.com> In-Reply-To: <54AB246C.3030204@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(57704003)(189002)(24454002)(479174004)(164054003)(377454003)(199003)(51704005)(68736005)(2900100001)(2950100001)(102836002)(15975445007)(97736003)(62966003)(36756003)(2501002)(21056001)(77156002)(87936001)(99286002)(66066001)(122556002)(54356999)(50986999)(76176999)(46102003)(2656002)(64706001)(120916001)(19580395003)(106356001)(92566001)(31966008)(40100003)(99396003)(19580405001)(106116001)(86362001)(107046002)(20776003)(107886001)(4396001)(105586002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C2860986D29B84E81256F392D28763B@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2015 16:35:11.0773 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qApksNiT-LGmMxYbBaVHxTh8dS0 Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 06 Jan 2015 16:35:20 -0000 Hi Christian, The only practical consequence I can envision is less noise during the approval process from the security camp. Of course, that=B9s all I can envision from ANY normative requirement in the security consideration section--at least in my field of work, such requirements have been regularly ignored by industry when convenient. Being a bit less sarcastic, your logic seems to be correct, and the second part of the sentence may therefore not be needed. Although I vaguely remember having seen a very similar formulation before in a different context. Mary, is this text from you? Where did the formulation come from? Thanks, Stephan On 1/5/15, 15:55, "Christian Groves" wrote: >Hello, > >What it is the practical result of the second "must", i.e. "and the >participants in the sessions MUST be made aware of this."? Does this >mean there's a legal disclaimer on the window saying that the >participants may not be those you expect? Do we need the second part of >the sentence pertaining to notification if we say that CLUE information >MUST not be used for authorization? > >Regards, Christian > >On 29/12/2014 10:03 PM, Roni Even wrote: >> >> Hi, >> >> OK with this change >> >> Roni Even >> >> As individual >> >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger >> *Sent:* 29 December, 2014 4:52 AM >> *To:* CLUE >> *Subject:* [clue] CLUE framework, security consideration section, >> level of mandation >> >> Hi, >> >> Mark and I are editing the framework document to address comments. >> >> This is with reference to my review, dated 12/16/2014, and >> specifically point 9 therein, reproduced as follows: >> >> 9. Page 70, first paragraphs. There are two unqualified =B3SHOULD=B2 >> statements. In the spirit of fast doc approval, I wouldn=B9t object if >> those were changed to =B3MUST=B2. I don=B9t recall that we discussed th= ese >> points before, but I could easily have missed that discussion. >> >> Unless someone objects the two SHOULD statements will be replaced with >> MUST. The modified paragraph in markup is shown below (also >> addressing comment 8 of my review, but that=B9s an editorial change and >> should be uncontroversial). Sorry for the messy formatting. >> >> I suggest a deadline of January 9, 2015, but do so without checking >> with the chairs=8Bwho are of course free to set a different date if they >> choose so. >> >> Regards, >> >> Stephan >> >> A separate data channel is established to transport the CLUE >> protocol messages. The contents of the CLUE protocol messages are >> based on information introduced in this document, which is >> represented by an XML schema for this information defined in the >> CLUE data model [ref]._The CLUE data model >>[I-D.ietf-clue-data-model-schema] defines through an XML schema the >>syntax to be used._ Some of the information which could possibly >>introduce privacy concerns is the xCard information as described in >>section 7.1.1.11. In addition, the (text) >> description field in the Media Capture attribute (section 7.1.1.7) >> could possibly reveal sensitive information or specific >> identities. The same would be true for the descriptions in the >> Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) >> attributes. One other important consideration for the >> information in the xCard as well as the description field in the >> Media Capture and Capture Scene View attributes is that while the >> endpoints involved in the session have been authenticated, there >> is no assurance that the information in the xCard or description >> fields is authentic. Thus, this informationSHOULD _MUST_ not be >>used to >> make any authorization decisions and the participants in the >> sessionsSHOULD _MUST_ be made aware of this. >> >> >> _______________________________________________ >> 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 nobody Tue Jan 6 18:28:21 2015 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 7080A1A88E6 for ; Tue, 6 Jan 2015 18:28: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 O4lR8hqcMBPT for ; Tue, 6 Jan 2015 18:28:17 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BBC1A88D5 for ; Tue, 6 Jan 2015 18:28:16 -0800 (PST) Received: from ppp118-209-218-232.lns20.mel8.internode.on.net ([118.209.218.232]:50545 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y8gKr-0005eu-5g for clue@ietf.org; Wed, 07 Jan 2015 13:27:01 +1100 Message-ID: <54AC99B8.7090500@nteczone.com> Date: Wed, 07 Jan 2015 13:28:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D52ED2E@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D52ED53@ESESSMB209.ericsson.se>, <5472781B.1050209@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5324F3@ESESSMB209.ericsson.se> <5473BE59.4070805@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D53548A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D53577E@ESESSMB209.ericsson.se> , <5474CDA8.8030004@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D5366AB@ESESSMB209.ericsson.se> <54751CD0.2070805@nteczone.com> In-Reply-To: <54751CD0.2070805@nteczone.com> Content-Type: text/plain; charset=utf-8; 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: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lC69Rf-nPAj8aPRnOcFO6FjNzmk Subject: [clue] draft-ietf-clue-datachannel-05 and DCEP 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, 07 Jan 2015 02:28:19 -0000 Hello Christer, all, I'm just wondering what the status of DCEP in draft-ietf-clue-datachannel is? The discussion below seemed to conclude that DCEP wasn't needed? Regards, Christian On 26/11/2014 11:20 AM, Christian Groves wrote: > I'm OK with dropping DCEP. It could be worth keeping the DCEP code > point as you say for non-O/A environment. > > Regards, Christian > > On 26/11/2014 6:17 AM, Christer Holmberg wrote: >> Hi, >> >> I agree with Paul. >> >> But, the question is still whether the CLUE data channel spec ahould >> still define the DCEP code point for the CLUE data channel, IF >> someone e.g. want to specify usage of CLUE in a non-O/A environment. >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ------------------------------------------------------------------------ >> From: Paul Kyzivat >> Sent: ‎25/‎11/‎2014 20:43 >> To: clue@ietf.org >> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and DCEP >> >> On 11/25/14 7:00 AM, Makaraju, Maridi Raju (Raju) wrote: >> > >> >> Hi, >> >> >> >>>> If you provide the SCTP port in the WebRTC API, then DCEP won't >> be used. >> >>> You meant "(stream) id" instead of "SCTP port"? >> >> >> >> Yes. >> >> >> >>> In WebRTC API createDataChannel(), use of DCEP is controlled by >> using >> >> "negotiated" parameter. (Stream) id specification only determines >> the stream >> >> id to be used. >> >> >> >> Ok. But, the point is that you can create a data channel without >> DCEP. >> > [Raju] >> > IMHO, I am in favor of not mandating DCEP for non-WebRTC device >> CLUE usage. Furthermore, to be consistent it may be better not to use >> DCEP even when CLUE is used by a WebRTC device. >> >> If we mandate using draft-ejzak for establishing the clue channel, then >> DCEP won't be *used*. I think we simply make a requirement for support >> of draft-ietf-rtcweb-data-channel, and don't mention >> draft-ietf-rtcweb-data-protocol. If there are dependencies between those >> two, then that is not our problem. (I thought data-channel had a >> dependency on data-protocol, but I don't see it now, which is a good >> thing.) >> >> Thanks, >> Paul >> >> > BR >> > Raju >> > >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >>> -----Original Message----- >> >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >> >>> Holmberg >> >>> Sent: Tuesday, November 25, 2014 5:24 AM >> >>> To: Christian Groves; clue@ietf.org >> >>> Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and >> >>> DCEP >> >>> >> >>> Hi, >> >>> >> >>> If I understood Paul's comment, DCEP is not required for >> compatibility >> >>> with WebRTC endpoints. If you provide the SCTP port in the WebRTC >> API, >> >>> then DCEP won't be used. >> >>> >> >>> The question is really whether we want to mandate non-WebRTC CLUE >> >>> devices to implement DCEP or not. >> >>> >> >>> Regards, >> >>> >> >>> Christer >> > _______________________________________________ >> > 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 nobody Thu Jan 8 09:47:52 2015 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 D02E11A8AE7 for ; Thu, 8 Jan 2015 09:47:49 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKKHr2UWGhLz for ; Thu, 8 Jan 2015 09:47:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0B91A8AEB for ; Thu, 8 Jan 2015 09:47:44 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1273.namprd07.prod.outlook.com (25.160.149.16) with Microsoft SMTP Server (TLS) id 15.1.49.12; Thu, 8 Jan 2015 17:47:20 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Thu, 8 Jan 2015 17:47:20 +0000 From: Stephan Wenger To: "Duckworth, Mark" , "pkyzivat@alum.mit.edu" , "clue@ietf.org" Thread-Topic: Can CLUE signaling help reduce size of SDP? Thread-Index: AdAeM+bVvJCWUiiPTsKFlo1aqiqeAQM9CKOA Date: Thu, 8 Jan 2015 17:47:19 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0701MB1273; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1273; x-forefront-prvs: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(51704005)(189002)(164054003)(53754006)(15975445007)(99396003)(4396001)(102836002)(120916001)(36756003)(68736005)(86362001)(19580395003)(40100003)(19580405001)(2900100001)(50986999)(54356999)(76176999)(2950100001)(19300405004)(20776003)(64706001)(62966003)(2656002)(107046002)(107886001)(77156002)(87936001)(2171001)(31966008)(16236675004)(21056001)(99286002)(101416001)(122556002)(92566001)(105586002)(97736003)(46102003)(19625215002)(2201001)(2501002)(66066001)(106356001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1273; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0D400044E4C2stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2015 17:47:19.3615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1273 Archived-At: Subject: Re: [clue] Can CLUE signaling help reduce size of SDP? 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, 08 Jan 2015 17:47:50 -0000 --_000_D0D400044E4C2stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, and happy new year! My apologies for this late reply, and thanks to Mark for reminding me. Yes, the language regarding the potential of reducing the SDP size through = information gathered in the CLUE message exchange was originally from me. = It stems from a time when we were considering (had agreed on? At least in = principle? I don't recall...) a multiphase negotiation: 1) set-up CLUE cha= nnel, 2) negotiate (over the CLUE channel, in a fashion similar to O/A) par= ameters that included parameters traditionally negotiated over SDP using th= e much richer XML-based CLUE syntax, and 3) only then pro-forma "negotiate"= via SDP O/A with the side effect of setting up the media. A few years ago= , that line of thought was popular. Personally, I still find it sensible, = given the limitations and awkwardness of SDP. But it's not how CLUE works = today, as far as I understand it. Paul's comments below sound sensible to me, but I'm not sufficiently well v= ersed in CLUE and O/A to assert correctness or lack thereof. Regards, Stephan From: , "Duckworth, Mark" > Date: Monday, December 22, 2014 at 14:10 To: Paul Kyzivat >, CLU= E >, Stephan Wenger > Subject: Can CLUE signaling help reduce size of SDP? >From Paul's comments on the framework: > Section 5: > > I'm struggling to understand the following paragraph: > > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during > the following SIP offer/answer exchange, and its reaction to SDP it > receives in that step. It is often a sensible implementation > choice to do so, as the representation of the media information > conveyed over the CLUE channel can dramatically cut down on the > size of SDP messages used in the O/A exchange that follows. > Spatial relationships associated with the Media can be included in > the Advertisement, and it is often sensible for the Media Consumer > to take those spatial relationships into account when tailoring the > SDP. > > This seems to me to say that the consumer can use the advertisement to > reduce the size of the sdp, which isn't really true. I think the problem > is that this text doesn't distinguish between what is done by providers > and consumers. > > For a provider, it may well be infeasible to send SDP covering every > encoding in the advertisement. It could potentially reduce the size of > SDP to a more manageable size by only offering those encodings that are > configured. BUT, as we have things structured now a consumer needs to > see the encodings in the SDP to decide what to configure. So this > potential can't be realized. > > For a consumer the potential is not to reduce the size of SDP, but > rather to reduce the number of encodings it must set up resources to > receive. It probably doesn't want to receive encodings that it doesn't > intend to use. I think this is the key point to make in this paragraph. > > (These comments also apply the the following paragraph.) I thought I understood this idea of reducing the SDP size, but now I can't recall the details of that. I think Stephan wrote these paragraphs. Stephan, can you explain what the intent was here? Thanks, Mark --_000_D0D400044E4C2stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <2B8A093FB17E5345A98DB7BC42D55723@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all, and happy new year!
My apologies for this late reply, and thanks to Mark for reminding me.=
Yes, the language regarding the potential of reducing the SDP size thr= ough information gathered in the CLUE message exchange was originally from = me.  It stems from a time when we were considering (had agreed on? &nb= sp;At least in principle?  I don’t recall…) a multiphase negotiation: 1) set-up CLUE channel, 2) negotiate (over the C= LUE channel, in a fashion similar to O/A) parameters that included paramete= rs traditionally negotiated over SDP using the much richer XML-based CLUE s= yntax, and 3) only then pro-forma “negotiate” via SDP O/A with the side effect of setting up the= media.  A few years ago, that line of thought was popular.  Pers= onally, I still find it sensible, given the limitations and awkwardness of = SDP.  But it’s not how CLUE works today, as far as I understand it.
Paul’s comments below sound sensible to me, but I’m not su= fficiently well versed in CLUE and O/A to assert correctness or lack thereo= f.
Regards,
Stephan


From: <Duckworth>, "Duck= worth, Mark" <Mark.Du= ckworth@polycom.com>
Date: Monday, December 22, 2014 at = 14:10
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, CLUE <clue@ietf.org>, Stephan Wenger <stewe@stewe.org>
Subject: Can CLUE signaling help re= duce size of SDP?

From Paul’s comments on the framework:

 

> Section 5:

>

> I'm struggling to understand the following p= aragraph:

>

>     Second, it MAY, but = is not necessarily REQUIRED to, use the

>     information provided= to tailor the SDP it is going to send during

>     the following SIP of= fer/answer exchange, and its reaction to SDP it

>     receives in that ste= p.  It is often a sensible implementation

>     choice to do so, as = the representation of the media information

>     conveyed over the CL= UE channel can dramatically cut down on the

>     size of SDP messages= used in the O/A exchange that follows.

>     Spatial relationship= s associated with the Media can be included in

>     the Advertisement, a= nd it is often sensible for the Media Consumer

>     to take those spatia= l relationships into account when tailoring the

>     SDP.

>

> This seems to me to say that the consumer ca= n use the advertisement to

> reduce the size of the sdp, which isn't real= ly true. I think the problem

> is that this text doesn't distinguish betwee= n what is done by providers

> and consumers.

>

> For a provider, it may well be infeasible to= send SDP covering every

> encoding in the advertisement. It could pote= ntially reduce the size of

> SDP to a more manageable size by only offeri= ng those encodings that are

> configured. BUT, as we have things structure= d now a consumer needs to

> see the encodings in the SDP to decide what = to configure. So this

> potential can't be realized.

>

> For a consumer the potential is not to reduc= e the size of SDP, but

> rather to reduce the number of encodings it = must set up resources to

> receive. It probably doesn't want to receive= encodings that it doesn't

> intend to use. I think this is the key point= to make in this paragraph.

>

> (These comments also apply the the following= paragraph.)

 

I thought I understood this idea of reducing the SDP= size, but now I

can’t recall the details of that.  I thin= k Stephan wrote these paragraphs.

 

Stephan, can you explain what the intent was here?

 

Thanks,
Mark

 

 --_000_D0D400044E4C2stewesteweorg_-- From nobody Thu Jan 8 14:00:34 2015 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 32A541A0095 for ; Thu, 8 Jan 2015 14:00:31 -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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmc41m_ITp2t for ; Thu, 8 Jan 2015 14:00:28 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4821A005D for ; Thu, 8 Jan 2015 14:00:27 -0800 (PST) Received: from [216.82.241.100] by server-17.bemta-8.messagelabs.com id 90/DC-13532-BFDFEA45; Thu, 08 Jan 2015 22:00:27 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-11.tower-220.messagelabs.com!1420754375!20770301!6 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3801 invoked from network); 8 Jan 2015 21:59:57 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-11.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2015 21:59:57 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 8 Jan 2015 13:59:52 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 8 Jan 2015 13:59:48 -0800 Thread-Topic: possible values for Person Type attribute Thread-Index: AdArjWqXeN9QNGyiTJSb/NUduTvJFQ== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] possible values for Person Type attribute 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, 08 Jan 2015 22:00:31 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There is a minor mismatch between framework and data model regarding the "p= erson type" attribute for a media capture. I have a proposal to align them= . These are the possible types listed in the framework: * Chairman - the person responsible for running the conference acco= rding to the agenda. * Vice-Chairman - the person responsible for assisting the chairman= in running the meeting. * Minute Taker - the person responsible for recording the minutes o= f the conference. * Member - the person has no particular responsibilities with respe= ct to running the meeting. * Presenter - the person is scheduled on the agenda to make a prese= ntation in the meeting. Note: This is not related to any "active speaker" f= unctionality. * Translator - the person is providing some form of translation or = commentary in the meeting. * Timekeeper - the person is responsible for maintaining the meetin= g schedule. Stephan proposed adding: * Observer - a Member without the right to influence the discussion= . These are the types listed in the data model: Looks like attendee is supposed to be the same as member. To make these consistent, I propose: * in the framework, change the term "member" to "attendee" * Accept Stephan's proposal, and add "observer" to the data model a= nd framework Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is a minor= mismatch between framework and data model regarding the “person type= ” attribute for a media capture.  I have a proposal to align the= m.

 

These are the possible types listed in the framework:

·      = ;   Chairman - the person responsi= ble for running the conference according to the agenda.

·      &= nbsp;  Vice-Chairman - the person respo= nsible for assisting the chairman in running the meeting.

·      = ;   Minute Taker - the person resp= onsible for recording the minutes of the conference.

·      &nbs= p;  Member - the person has no particul= ar responsibilities with respect to running the meeting.

·      =    Presenter - the person is sched= uled on the agenda to make a presentation in the meeting. Note: This is not= related to any "active speaker" functionality.

·   =       Translator - = the person is providing some form of translation or commentary in the meeti= ng.

·         Timekeeper - the person is responsible for maintaining the meeting sc= hedule.=

Stephan proposed adding:

·      = ;   Observer – a Member with= out the right to influence the discussion.

These are the types listed in the data model:

<xs:enumeration value=3D"chairm= an"/>

<xs:enumeration value=3D"vice-chairman"/>

<xs:enumeration value=3D&q= uot;minute taker"/>

<xs:enumeration value=3D"presenter"/>

<xs:enumeration = value=3D"translator"/>

<xs:enumeration value=3D"timekeeper"/&g= t;

<xs:enu= meration value=3D"attendee"/>

 

Looks like attendee is suppose= d to be the same as member.

 <= /o:p>

To make these consistent, I propose:

· &nbs= p;       in the frame= work, change the term “member” to “attendee”

·&= nbsp;        Acc= ept Stephan’s proposal, and add “observer” to the data mo= del and framework

Mark=

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714CRPMBOXPRD08p_-- From nobody Thu Jan 8 14:08:11 2015 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 421C51A0193 for ; Thu, 8 Jan 2015 14:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ioem3W2FayPo for ; Thu, 8 Jan 2015 14:08:06 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98951A00FA for ; Thu, 8 Jan 2015 14:08:06 -0800 (PST) Received: from [216.82.254.20] by server-17.bemta-7.messagelabs.com id 45/37-02679-6CFFEA45; Thu, 08 Jan 2015 22:08:06 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1420754865!19571524!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23051 invoked from network); 8 Jan 2015 22:07:46 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2015 22:07:46 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by crpehubprd02.polycom.com (10.236.0.154) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 8 Jan 2015 14:04:34 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 8 Jan 2015 14:04:33 -0800 From: "Duckworth, Mark" To: Stephan Wenger , Christian Groves , "clue@ietf.org" Date: Thu, 8 Jan 2015 14:04:30 -0800 Thread-Topic: [clue] CLUE framework, security consideration section, level of mandation Thread-Index: AQHQKUMbkgW5TlAA8EuhIA6D3OnVKpyyxNGAgAQF4RA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6718@CRPMBOXPRD08.polycom.com> References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> <54AB246C.3030204@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 08 Jan 2015 22:08:09 -0000 I agree with Christian. So the proposal is to change the first SHOULD to M= UST, and delete the last part of the sentence. So the new text would be: One other important consideration for the information in the xCard as well = as the description field in the Media Capture and Capture Scene View attrib= utes is that while the endpoints involved in the session have been authenti= cated, there is no assurance that the information in the xCard or descripti= on fields is authentic. Thus, this information MUST NOT be used to make an= y authorization decisions. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger > Sent: Tuesday, January 06, 2015 11:35 AM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] CLUE framework, security consideration section, level= of > mandation >=20 > Hi Christian, > The only practical consequence I can envision is less noise during the > approval process from the security camp. Of course, that=B9s all I can > envision from ANY normative requirement in the security consideration > section--at least in my field of work, such requirements have been > regularly ignored by industry when convenient. > Being a bit less sarcastic, your logic seems to be correct, and the secon= d > part of the sentence may therefore not be needed. Although I vaguely > remember having seen a very similar formulation before in a different > context. Mary, is this text from you? Where did the formulation come > from? > Thanks, > Stephan >=20 >=20 > On 1/5/15, 15:55, "Christian Groves" > wrote: >=20 > >Hello, > > > >What it is the practical result of the second "must", i.e. "and the > >participants in the sessions MUST be made aware of this."? Does this > >mean there's a legal disclaimer on the window saying that the > >participants may not be those you expect? Do we need the second part of > >the sentence pertaining to notification if we say that CLUE information > >MUST not be used for authorization? > > > >Regards, Christian > > > >On 29/12/2014 10:03 PM, Roni Even wrote: > >> > >> Hi, > >> > >> OK with this change > >> > >> Roni Even > >> > >> As individual > >> > >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan > Wenger > >> *Sent:* 29 December, 2014 4:52 AM > >> *To:* CLUE > >> *Subject:* [clue] CLUE framework, security consideration section, > >> level of mandation > >> > >> Hi, > >> > >> Mark and I are editing the framework document to address comments. > >> > >> This is with reference to my review, dated 12/16/2014, and > >> specifically point 9 therein, reproduced as follows: > >> > >> 9. Page 70, first paragraphs. There are two unqualified =B3SHOULD=B2 > >> statements. In the spirit of fast doc approval, I wouldn=B9t object i= f > >> those were changed to =B3MUST=B2. I don=B9t recall that we discussed = these > >> points before, but I could easily have missed that discussion. > >> > >> Unless someone objects the two SHOULD statements will be replaced > with > >> MUST. The modified paragraph in markup is shown below (also > >> addressing comment 8 of my review, but that=B9s an editorial change an= d > >> should be uncontroversial). Sorry for the messy formatting. > >> > >> I suggest a deadline of January 9, 2015, but do so without checking > >> with the chairs >> choose so. > >> > >> Regards, > >> > >> Stephan > >> > >> A separate data channel is established to transport the CLUE > >> protocol messages. The contents of the CLUE protocol messages are > >> based on information introduced in this document, which is > >> represented by an XML schema for this information defined in the > >> CLUE data model [ref]._The CLUE data model > >>[I-D.ietf-clue-data-model-schema] defines through an XML schema the > >>syntax to be used._ Some of the information which could possibly > >>introduce privacy concerns is the xCard information as described in > >>section 7.1.1.11. In addition, the (text) > >> description field in the Media Capture attribute (section 7.1.1.7) > >> could possibly reveal sensitive information or specific > >> identities. The same would be true for the descriptions in the > >> Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) > >> attributes. One other important consideration for the > >> information in the xCard as well as the description field in the > >> Media Capture and Capture Scene View attributes is that while the > >> endpoints involved in the session have been authenticated, there > >> is no assurance that the information in the xCard or description > >> fields is authentic. Thus, this informationSHOULD _MUST_ not be > >>used to > >> make any authorization decisions and the participants in the > >> sessionsSHOULD _MUST_ be made aware of this. > >> > >> > >> _______________________________________________ > >> 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 nobody Thu Jan 8 14:32:11 2015 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 B08CB1A0095 for ; Thu, 8 Jan 2015 14:32:08 -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 iAflKOUzt7Km for ; Thu, 8 Jan 2015 14:32:05 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EB81A1B4F for ; Thu, 8 Jan 2015 14:32:05 -0800 (PST) Received: from ppp118-209-218-232.lns20.mel8.internode.on.net ([118.209.218.232]:51190 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y9Laz-0001AA-1Z for clue@ietf.org; Fri, 09 Jan 2015 09:30:25 +1100 Message-ID: <54AF055A.4090200@nteczone.com> Date: Fri, 09 Jan 2015 09:31:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "clue@ietf.org" References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> <54AB246C.3030204@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6718@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6718@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 08 Jan 2015 22:32:08 -0000 Hello Mark, Sounds good. Christian On 9/01/2015 9:04 AM, Duckworth, Mark wrote: > I agree with Christian. So the proposal is to change the first SHOULD to MUST, and delete the last part of the sentence. So the new text would be: > > One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information MUST NOT be used to make any authorization decisions. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger >> Sent: Tuesday, January 06, 2015 11:35 AM >> To: Christian Groves; clue@ietf.org >> Subject: Re: [clue] CLUE framework, security consideration section, level of >> mandation >> >> Hi Christian, >> The only practical consequence I can envision is less noise during the >> approval process from the security camp. Of course, thatąs all I can >> envision from ANY normative requirement in the security consideration >> section--at least in my field of work, such requirements have been >> regularly ignored by industry when convenient. >> Being a bit less sarcastic, your logic seems to be correct, and the second >> part of the sentence may therefore not be needed. Although I vaguely >> remember having seen a very similar formulation before in a different >> context. Mary, is this text from you? Where did the formulation come >> from? >> Thanks, >> Stephan >> >> >> On 1/5/15, 15:55, "Christian Groves" >> wrote: >> >>> Hello, >>> >>> What it is the practical result of the second "must", i.e. "and the >>> participants in the sessions MUST be made aware of this."? Does this >>> mean there's a legal disclaimer on the window saying that the >>> participants may not be those you expect? Do we need the second part of >>> the sentence pertaining to notification if we say that CLUE information >>> MUST not be used for authorization? >>> >>> Regards, Christian >>> >>> On 29/12/2014 10:03 PM, Roni Even wrote: >>>> Hi, >>>> >>>> OK with this change >>>> >>>> Roni Even >>>> >>>> As individual >>>> >>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan >> Wenger >>>> *Sent:* 29 December, 2014 4:52 AM >>>> *To:* CLUE >>>> *Subject:* [clue] CLUE framework, security consideration section, >>>> level of mandation >>>> >>>> Hi, >>>> >>>> Mark and I are editing the framework document to address comments. >>>> >>>> This is with reference to my review, dated 12/16/2014, and >>>> specifically point 9 therein, reproduced as follows: >>>> >>>> 9. Page 70, first paragraphs. There are two unqualified łSHOULD˛ >>>> statements. In the spirit of fast doc approval, I wouldnąt object if >>>> those were changed to łMUST˛. I donąt recall that we discussed these >>>> points before, but I could easily have missed that discussion. >>>> >>>> Unless someone objects the two SHOULD statements will be replaced >> with >>>> MUST. The modified paragraph in markup is shown below (also >>>> addressing comment 8 of my review, but thatąs an editorial change and >>>> should be uncontroversial). Sorry for the messy formatting. >>>> >>>> I suggest a deadline of January 9, 2015, but do so without checking >>>> with the chairs>>> choose so. >>>> >>>> Regards, >>>> >>>> Stephan >>>> >>>> A separate data channel is established to transport the CLUE >>>> protocol messages. The contents of the CLUE protocol messages are >>>> based on information introduced in this document, which is >>>> represented by an XML schema for this information defined in the >>>> CLUE data model [ref]._The CLUE data model >>>> [I-D.ietf-clue-data-model-schema] defines through an XML schema the >>>> syntax to be used._ Some of the information which could possibly >>>> introduce privacy concerns is the xCard information as described in >>>> section 7.1.1.11. In addition, the (text) >>>> description field in the Media Capture attribute (section 7.1.1.7) >>>> could possibly reveal sensitive information or specific >>>> identities. The same would be true for the descriptions in the >>>> Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) >>>> attributes. One other important consideration for the >>>> information in the xCard as well as the description field in the >>>> Media Capture and Capture Scene View attributes is that while the >>>> endpoints involved in the session have been authenticated, there >>>> is no assurance that the information in the xCard or description >>>> fields is authentic. Thus, this informationSHOULD _MUST_ not be >>>> used to >>>> make any authorization decisions and the participants in the >>>> sessionsSHOULD _MUST_ be made aware of this. >>>> >>>> >>>> _______________________________________________ >>>> 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 nobody Thu Jan 8 14:32:45 2015 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 BB3241A0095 for ; Thu, 8 Jan 2015 14:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVVWy1p5uG6K for ; Thu, 8 Jan 2015 14:32:39 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F6F1A1B4F for ; Thu, 8 Jan 2015 14:32:39 -0800 (PST) Received: from [216.82.249.212] by server-14.bemta-12.messagelabs.com id C4/77-02695-6850FA45; Thu, 08 Jan 2015 22:32:38 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1420756299!18735050!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6867 invoked from network); 8 Jan 2015 22:31:39 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-7.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2015 22:31:39 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Thu, 8 Jan 2015 14:27:52 -0800 From: "Duckworth, Mark" To: Stephan Wenger , "pkyzivat@alum.mit.edu" , "clue@ietf.org" Date: Thu, 8 Jan 2015 14:27:49 -0800 Thread-Topic: Can CLUE signaling help reduce size of SDP? Thread-Index: AdAeM+bVvJCWUiiPTsKFlo1aqiqeAQM9CKOAABp9bMA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.polycom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: Re: [clue] Can CLUE signaling help reduce size of SDP? 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, 08 Jan 2015 22:32:43 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay, so based on Paul and Stephan's comments, here is a proposal to change= those two paragraphs to remove the part about reducing SDP size, and add P= aul's point about not wasting consumer resources. Proposed changed text: Also, the Consumer MAY use the information provided to tailor the SDP it is= going to send during any following SIP offer/answer exchange, and its reac= tion to SDP it receives in that step. It is often a sensible implementatio= n choice to do so. Spatial relationships associated with the Media can be = included in the Advertisement, and it is often sensible for the Media Consu= mer to take those spatial relationships into account when tailoring the SDP= . The Consumer can also limit the number of encodings it must set up resou= rces to receive, and not waste resources on unwanted encodings, because it = has the Provider's Advertisement information ahead of time to determine wha= t it really wants to receive. This initial CLUE exchange is followed by an SDP offer/answer exchange that= not only establishes those aspects of the media that have not been "negoti= ated" over CLUE, but has also the side effect of setting up the media trans= mission itself, involving potentially security exchanges, ICE, and whatnot.= This step is plain vanilla SIP. Mark From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, January 08, 2015 12:47 PM To: Duckworth, Mark; pkyzivat@alum.mit.edu; clue@ietf.org Subject: Re: Can CLUE signaling help reduce size of SDP? Hi all, and happy new year! My apologies for this late reply, and thanks to Mark for reminding me. Yes, the language regarding the potential of reducing the SDP size through = information gathered in the CLUE message exchange was originally from me. = It stems from a time when we were considering (had agreed on? At least in = principle? I don't recall...) a multiphase negotiation: 1) set-up CLUE cha= nnel, 2) negotiate (over the CLUE channel, in a fashion similar to O/A) par= ameters that included parameters traditionally negotiated over SDP using th= e much richer XML-based CLUE syntax, and 3) only then pro-forma "negotiate"= via SDP O/A with the side effect of setting up the media. A few years ago= , that line of thought was popular. Personally, I still find it sensible, = given the limitations and awkwardness of SDP. But it's not how CLUE works = today, as far as I understand it. Paul's comments below sound sensible to me, but I'm not sufficiently well v= ersed in CLUE and O/A to assert correctness or lack thereof. Regards, Stephan From: , "Duckworth, Mark" > Date: Monday, December 22, 2014 at 14:10 To: Paul Kyzivat >, CLU= E >, Stephan Wenger > Subject: Can CLUE signaling help reduce size of SDP? >From Paul's comments on the framework: > Section 5: > > I'm struggling to understand the following paragraph: > > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during > the following SIP offer/answer exchange, and its reaction to SDP it > receives in that step. It is often a sensible implementation > choice to do so, as the representation of the media information > conveyed over the CLUE channel can dramatically cut down on the > size of SDP messages used in the O/A exchange that follows. > Spatial relationships associated with the Media can be included in > the Advertisement, and it is often sensible for the Media Consumer > to take those spatial relationships into account when tailoring the > SDP. > > This seems to me to say that the consumer can use the advertisement to > reduce the size of the sdp, which isn't really true. I think the problem > is that this text doesn't distinguish between what is done by providers > and consumers. > > For a provider, it may well be infeasible to send SDP covering every > encoding in the advertisement. It could potentially reduce the size of > SDP to a more manageable size by only offering those encodings that are > configured. BUT, as we have things structured now a consumer needs to > see the encodings in the SDP to decide what to configure. So this > potential can't be realized. > > For a consumer the potential is not to reduce the size of SDP, but > rather to reduce the number of encodings it must set up resources to > receive. It probably doesn't want to receive encodings that it doesn't > intend to use. I think this is the key point to make in this paragraph. > > (These comments also apply the the following paragraph.) I thought I understood this idea of reducing the SDP size, but now I can't recall the details of that. I think Stephan wrote these paragraphs. Stephan, can you explain what the intent was here? Thanks, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay, so based on Paul and Stephan’s comments, here is = a proposal to change those two paragraphs to remove the part about reducing= SDP size, and add Paul’s point about not wasting consumer resources.=

 

Proposed changed text:

 

Also, the Consumer MAY use the information provid= ed to tailor the SDP it is going to send during any following SIP offer/ans= wer exchange, and its reaction to SDP it receives in that step.  It is= often a sensible implementation choice to do so.  Spatial relationshi= ps associated with the Media can be included in the Advertisement, and it i= s often sensible for the Media Consumer to take those spatial relationships= into account when tailoring the SDP.  The Consumer can also limit the= number of encodings it must set up resources to receive, and not waste res= ources on unwanted encodings, because it has the Provider’s Advertise= ment information ahead of time to determine what it really wants to receive= .

<= o:p> 

This initial CLUE exchange is followed by an SDP offer/answer exchange t= hat not only establishes those aspects of the media that have not been &quo= t;negotiated" over CLUE, but has also the side effect of setting up th= e media transmission itself, involving potentially security exchanges, ICE,= and whatnot.  This step is plain vanilla SIP.

 

Mark=

 

From: Stephan Wenger [mailt= o:stewe@stewe.org]
Sent: Thursday, January 08, 2015 12:47 PM
= To: Duckworth, Mark; pkyzivat@alum.mit.edu; clue@ietf.org
Subj= ect: Re: Can CLUE signaling help reduce size of SDP?<= /p>

 

Hi all, and happy new = year!

My apologies for this late reply, and thanks t= o Mark for reminding me.

Yes, the language regarding= the potential of reducing the SDP size through information gathered in the= CLUE message exchange was originally from me.  It stems from a time w= hen we were considering (had agreed on?  At least in principle?  = I don’t recall…) a multiphase negotiation: 1) set-up CLUE chann= el, 2) negotiate (over the CLUE channel, in a fashion similar to O/A) param= eters that included parameters traditionally negotiated over SDP using the = much richer XML-based CLUE syntax, and 3) only then pro-forma “negoti= ate” via SDP O/A with the side effect of setting up the media.  = A few years ago, that line of thought was popular.  Personally, I stil= l find it sensible, given the limitations and awkwardness of SDP.  But= it’s not how CLUE works today, as far as I understand it.=

Paul’s comments below sound sensible to me, but I’= m not sufficiently well versed in CLUE and O/A to assert correctness or lac= k thereof.

Regards,

=

Stephan

 

 

Fro= m: <Duckworth>, "Duckwort= h, Mark" <Mark.Duckwo= rth@polycom.com>
Date: Monday, December 22, 2014 at 14:10<= br>To: Paul Kyzivat <pky= zivat@alum.mit.edu>, CLUE <clue@= ietf.org>, Stephan Wenger <ste= we@stewe.org>
Subject: Can CLUE signaling help reduce size= of SDP?

 

From Paul’s comme= nts on the framework:

 

> Section 5:

>

> I'm struggling to understand t= he following paragraph:

>

>     Second, it MAY, but = is not necessarily REQUIRED to, use the

>     informat= ion provided to tailor the SDP it is going to send during=

>   &n= bsp; the following SIP offer/answer exchange, and its reaction to SDP = it

>     receives in that step.  It is often a se= nsible implementation

>     choice to do so, as the re= presentation of the media information

>     conveyed o= ver the CLUE channel can dramatically cut down on the

=

>    =  size of SDP messages used in the O/A exchange that follows.

>  =    Spatial relationships associated with the Media can be in= cluded in

>     the Advertisement, and it is often sen= sible for the Media Consumer

<= span style=3D'color:black'>>     to take those spati= al relationships into account when tailoring the

>     = ;SDP.

>

> This seems to me to say that the consumer can use the advertis= ement to

> reduce the size of the sdp, which isn't really true. I think th= e problem

> is that this text doesn't distinguish between what is done by = providers

> and consumers.

>

> For a provider, it may well be infeasibl= e to send SDP covering every

<= span style=3D'color:black'>> encoding in the advertisement. It could pot= entially reduce the size of

> SDP to a more manageable size by only offeri= ng those encodings that are

> configured. BUT, as we have things structure= d now a consumer needs to

> see the encodings in the SDP to decide what to= configure. So this

> potential can't be realized.

>

> For a consumer t= he potential is not to reduce the size of SDP, but

> rather to reduce the = number of encodings it must set up resources to

> receive. It probably doe= sn't want to receive encodings that it doesn't

> intend to use. I think th= is is the key point to make in this paragraph.

>

> (These comments also = apply the the following paragraph.)

 

I thought I understood this idea of reduci= ng the SDP size, but now I

can’t recall the details of that.  I thin= k Stephan wrote these paragraphs.

 

Stephan, can you explain what the intent was= here?

 

Thanks,
Mark

 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721CRPMBOXPRD08p_-- From nobody Thu Jan 8 14:33:16 2015 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 51DAB1A0095 for ; Thu, 8 Jan 2015 14:33: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 l_Q-b_opruBG for ; Thu, 8 Jan 2015 14:33:13 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649101A1B1B for ; Thu, 8 Jan 2015 14:33:13 -0800 (PST) Received: from ppp118-209-218-232.lns20.mel8.internode.on.net ([118.209.218.232]:51198 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y9Lc5-0001K6-Sv for clue@ietf.org; Fri, 09 Jan 2015 09:31:34 +1100 Message-ID: <54AF059F.9090606@nteczone.com> Date: Fri, 09 Jan 2015 09:33:03 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] possible values for Person Type attribute 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, 08 Jan 2015 22:33:15 -0000 Hello Mark, I'm OK with the proposed changes. Regards, Christian On 9/01/2015 8:59 AM, Duckworth, Mark wrote: > > There is a minor mismatch between framework and data model regarding > the “person type” attribute for a media capture. I have a proposal to > align them. > > These are the possible types listed in the framework: > > ·Chairman - the person responsible for running the conference > according to the agenda. > > ·Vice-Chairman - the person responsible for assisting the chairman in > running the meeting. > > ·Minute Taker - the person responsible for recording the minutes of > the conference. > > ·Member - the person has no particular responsibilities with respect > to running the meeting. > > ·Presenter - the person is scheduled on the agenda to make a > presentation in the meeting. Note: This is not related to any "active > speaker" functionality. > > ·Translator - the person is providing some form of translation or > commentary in the meeting. > > ·Timekeeper - the person is responsible for maintaining the meeting > schedule. > > Stephan proposed adding: > > ·Observer – a Member without the right to influence the discussion. > > These are the types listed in the data model: > > > > > > > > > > > > > > > > Looks like attendee is supposed to be the same as member. > > To make these consistent, I propose: > > ·in the framework, change the term “member” to “attendee” > > ·Accept Stephan’s proposal, and add “observer” to the data model and > framework > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jan 8 14:35:39 2015 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 2C3F11A1B1B for ; Thu, 8 Jan 2015 14:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrwYQYy5-D2S for ; Thu, 8 Jan 2015 14:35:22 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.14]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2291A0177 for ; Thu, 8 Jan 2015 14:35:22 -0800 (PST) Received: from [216.82.249.212] by server-14.bemta-12.messagelabs.com id D2/BB-02695-A260FA45; Thu, 08 Jan 2015 22:35:22 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-219.messagelabs.com!1420756485!18758397!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7488 invoked from network); 8 Jan 2015 22:35:13 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-13.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 8 Jan 2015 22:35:13 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 8 Jan 2015 14:35:03 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 8 Jan 2015 14:35:02 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 8 Jan 2015 14:35:00 -0800 Thread-Topic: [clue] Consumer choosing subset of Captures from MCC Thread-Index: AdApRclcF4LTv+O3QveYcpWyW9CI7ACTOepA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> In-Reply-To: <54AB28EA.8040409@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 Archived-At: Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 08 Jan 2015 22:35:27 -0000 I see Paul and Rob agreeing with the proposal that says the Provider should= not be required to honor a request in a Configure message to use only spec= ific Captures in an MCC. Christian prefers to add an attribute the Provide= r can set, telling the Consumer whether or not it will accept such requests= . Either way is okay with me. Any further discussion? How do we choose which way to go? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Monday, January 05, 2015 7:15 PM > To: clue@ietf.org > Subject: Re: [clue] Consumer choosing subset of Captures from MCC >=20 > Looking from a user perspective I have trouble with this change. If the > MP provider receives an MCC and gives the participants a chance to > choose the contributing captures then the user will expect to receive > their choice. There's no feedback that their choice isn't allowed other > than the captures they don't want appear in their media stream. They'll > probably try to do the "choose" procedure again figuring that they did > something wrong in the first place. >=20 > So I don't support going from effectively a "MUST" to "a suggestion". I > think the suggestion of adding an MCC attribute to indicate that a > subset cannot be chosen is a more robust solution. >=20 > Regards, Christian >=20 > On 23/12/2014 4:23 AM, Duckworth, Mark wrote: > > > > We discussed this at the design team meeting last week. See Rob's > > email from December 15. The issue is we think the Provider should not > > be required to honor a request in a Configure message to use only > > specific Captures in an MCC. Does the group agree with this proposed > > change? > > > > Current text in the framework: > > > > - The Consumer may or may not choose to receive all the indicated > > Captures. Therefore it can choose to receive a sub-set of Captures > > indicated by the MCC. > > > > For example if the Consumer receives: > > > > MCC1(VC1,VC2,VC3){attributes} > > > > A Consumer could choose all the Captures within a MCCs however if the > > Consumer determines that it doesn't want VC3 it can return > > MCC1(VC1,VC2). If it wants all the individual Captures then it > > returns only the MCC identity (i.e. MCC1). If the MCC in the > > advertisement does not reference any individual captures, then the > > Consumer cannot choose what is included in the MCC, it is up to the > > Provider to decide. > > > > Proposed new text in the framework: > > > > - The Consumer may or may not request to receive all the indicated > > Captures. Therefore it can request to receive a sub-set of Captures > > indicated by the MCC. > > > > For example if the Consumer receives an Advertisement with: > > > > MCC1(VC1,VC2,VC3){attributes} > > > > A Consumer could choose all the Captures within the MCC, however if > > the Consumer determines that it doesn't want VC3 it can return > > MCC1(VC1,VC2) in the Configure message. This is just a suggestion to > > the Provider. The Provider MAY consider this suggestion when deciding > > which Captures to include in the MCC Capture Encoding it sends to the > > Consumer. If the Consumer wants all the individual Captures then it > > returns only the MCC identity (i.e. MCC1). If the MCC in the > > advertisement does not reference any individual captures, then the > > Consumer cannot choose what is included in the MCC, it is up to the > > Provider to decide. > > > > Another possibility is to add a new MCC attribute in the > > advertisement, so the Provider can indicate whether or not it will > > accept requests asking for only a subset of captures in an MCC. > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jan 8 15:32:17 2015 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 E73441A8BB3 for ; Thu, 8 Jan 2015 15:32: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 7y97f6lzmGq2 for ; Thu, 8 Jan 2015 15:32:13 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1F81A901F for ; Thu, 8 Jan 2015 15:32:10 -0800 (PST) Received: from ppp118-209-218-232.lns20.mel8.internode.on.net ([118.209.218.232]:51876 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1Y9MX7-0003L6-22 for clue@ietf.org; Fri, 09 Jan 2015 10:30:29 +1100 Message-ID: <54AF136F.3010108@nteczone.com> Date: Fri, 09 Jan 2015 10:31:59 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "clue@ietf.org" 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: Archived-At: Subject: [clue] SCTP port in draft-ietf-clue-datachannel-05 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, 08 Jan 2015 23:32:15 -0000 Hello Christer, In draft-ietf-clue-datachannel-05 it says that the sctp-port is optional, i.e. 3.2.1.2. SDP sctp-port Attribute As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute value is set to the SCTP port of the SCTPoDTLS association. NOTE: Usage of the SDP sctp-port attribute is optional. As defined in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then the default value is 5000. However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. BTW clause 4.5 in the draft should probably also be updated to add a=sctp-port because it is mandatory. Regards, Christian From nobody Thu Jan 8 17:28:06 2015 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 BF7381A7001 for ; Thu, 8 Jan 2015 17:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BvUoTTKtxC0 for ; Thu, 8 Jan 2015 17:28:02 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0131.outbound.protection.outlook.com [65.55.169.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3DE61A6FE9 for ; Thu, 8 Jan 2015 17:28:01 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1162.namprd07.prod.outlook.com (25.160.146.14) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 9 Jan 2015 01:27:59 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 9 Jan 2015 01:27:58 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Fri, 9 Jan 2015 01:27:58 +0000 From: Stephan Wenger To: "Duckworth, Mark" , "pkyzivat@alum.mit.edu" , "clue@ietf.org" Thread-Topic: Can CLUE signaling help reduce size of SDP? Thread-Index: AdAeM+bVvJCWUiiPTsKFlo1aqiqeAQM9CKOAABp9bMD//6zfgA== Date: Fri, 9 Jan 2015 01:27:58 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-dmarcaction: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005003); SRVR:CY1PR0701MB1276; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1276; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(164054003)(377454003)(53754006)(51704005)(199003)(99396003)(19625215002)(86362001)(54356999)(561944003)(2501002)(102836002)(15975445007)(120916001)(2900100001)(19580405001)(2950100001)(106356001)(19300405004)(68736005)(19580395003)(105586002)(66066001)(64706001)(101416001)(40100003)(4396001)(46102003)(36756003)(107886001)(62966003)(122556002)(77156002)(76176999)(97736003)(50986999)(16236675004)(2656002)(20776003)(92566001)(107046002)(87936001)(31966008)(2171001)(2201001)(99286002)(21056001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1276; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0D46E8F4E52Cstewesteweorg_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2015 01:27:58.5210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1276 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1162; X-OriginatorOrg: stewe.org Archived-At: Subject: Re: [clue] Can CLUE signaling help reduce size of SDP? 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, 09 Jan 2015 01:28:06 -0000 --_000_D0D46E8F4E52Cstewesteweorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good with me. Stephan From: , "Duckworth, Mark" > Date: Thursday, January 8, 2015 at 14:27 To: Stephan Wenger >, Paul Kyzivat = >, CLUE > Subject: RE: Can CLUE signaling help reduce size of SDP? Okay, so based on Paul and Stephan=92s comments, here is a proposal to chan= ge those two paragraphs to remove the part about reducing SDP size, and add= Paul=92s point about not wasting consumer resources. Proposed changed text: Also, the Consumer MAY use the information provided to tailor the SDP it is= going to send during any following SIP offer/answer exchange, and its reac= tion to SDP it receives in that step. It is often a sensible implementatio= n choice to do so. Spatial relationships associated with the Media can be = included in the Advertisement, and it is often sensible for the Media Consu= mer to take those spatial relationships into account when tailoring the SDP= . The Consumer can also limit the number of encodings it must set up resou= rces to receive, and not waste resources on unwanted encodings, because it = has the Provider=92s Advertisement information ahead of time to determine w= hat it really wants to receive. This initial CLUE exchange is followed by an SDP offer/answer exchange that= not only establishes those aspects of the media that have not been "negoti= ated" over CLUE, but has also the side effect of setting up the media trans= mission itself, involving potentially security exchanges, ICE, and whatnot.= This step is plain vanilla SIP. Mark From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, January 08, 2015 12:47 PM To: Duckworth, Mark; pkyzivat@alum.mit.edu; c= lue@ietf.org Subject: Re: Can CLUE signaling help reduce size of SDP? Hi all, and happy new year! My apologies for this late reply, and thanks to Mark for reminding me. Yes, the language regarding the potential of reducing the SDP size through = information gathered in the CLUE message exchange was originally from me. = It stems from a time when we were considering (had agreed on? At least in = principle? I don=92t recall=85) a multiphase negotiation: 1) set-up CLUE c= hannel, 2) negotiate (over the CLUE channel, in a fashion similar to O/A) p= arameters that included parameters traditionally negotiated over SDP using = the much richer XML-based CLUE syntax, and 3) only then pro-forma =93negoti= ate=94 via SDP O/A with the side effect of setting up the media. A few yea= rs ago, that line of thought was popular. Personally, I still find it sens= ible, given the limitations and awkwardness of SDP. But it=92s not how CLU= E works today, as far as I understand it. Paul=92s comments below sound sensible to me, but I=92m not sufficiently we= ll versed in CLUE and O/A to assert correctness or lack thereof. Regards, Stephan From: , "Duckworth, Mark" > Date: Monday, December 22, 2014 at 14:10 To: Paul Kyzivat >, CLU= E >, Stephan Wenger > Subject: Can CLUE signaling help reduce size of SDP? >From Paul=92s comments on the framework: > Section 5: > > I'm struggling to understand the following paragraph: > > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during > the following SIP offer/answer exchange, and its reaction to SDP it > receives in that step. It is often a sensible implementation > choice to do so, as the representation of the media information > conveyed over the CLUE channel can dramatically cut down on the > size of SDP messages used in the O/A exchange that follows. > Spatial relationships associated with the Media can be included in > the Advertisement, and it is often sensible for the Media Consumer > to take those spatial relationships into account when tailoring the > SDP. > > This seems to me to say that the consumer can use the advertisement to > reduce the size of the sdp, which isn't really true. I think the problem > is that this text doesn't distinguish between what is done by providers > and consumers. > > For a provider, it may well be infeasible to send SDP covering every > encoding in the advertisement. It could potentially reduce the size of > SDP to a more manageable size by only offering those encodings that are > configured. BUT, as we have things structured now a consumer needs to > see the encodings in the SDP to decide what to configure. So this > potential can't be realized. > > For a consumer the potential is not to reduce the size of SDP, but > rather to reduce the number of encodings it must set up resources to > receive. It probably doesn't want to receive encodings that it doesn't > intend to use. I think this is the key point to make in this paragraph. > > (These comments also apply the the following paragraph.) I thought I understood this idea of reducing the SDP size, but now I can=92t recall the details of that. I think Stephan wrote these paragraphs= . Stephan, can you explain what the intent was here? Thanks, Mark --_000_D0D46E8F4E52Cstewesteweorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8B6ED02D0342284DBE4842113D0397B6@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Good with me.
Stephan

From: <Duckworth>, "Duck= worth, Mark" <Mark.Du= ckworth@polycom.com>
Date: Thursday, January 8, 2015 at = 14:27
To: Stephan Wenger <stewe@stewe.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, CLUE <clue@ietf.org>
Subject: RE: Can CLUE signaling hel= p reduce size of SDP?

Okay, so based on Paul= and Stephan=92s comments, here is a proposal to change those two paragraph= s to remove the part about reducing SDP size, and add Paul=92s point about = not wasting consumer resources.

 

Proposed changed text:=

 

Also, the Consumer MAY= use the information provided to tailor the SDP it is going to send during = any following SIP offer/answer exchange, and its reaction to SDP it receive= s in that step.  It is often a sensible implementation choice to do so.  Spatial relationships associated wit= h the Media can be included in the Advertisement, and it is often sensible = for the Media Consumer to take those spatial relationships into account whe= n tailoring the SDP.  The Consumer can also limit the number of encodings it must set up resources to receive, an= d not waste resources on unwanted encodings, because it has the Provider=92= s Advertisement information ahead of time to determine what it really wants= to receive.

 

This initial CLUE exch= ange is followed by an SDP offer/answer exchange that not only establishes = those aspects of the media that have not been "negotiated" over C= LUE, but has also the side effect of setting up the media transmission itself, involving potentially security exchanges, I= CE, and whatnot.  This step is plain vanilla SIP.

 

Mark=

 

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Thursday, January 08, 2015 12:47 PM
To: Duckworth, Mark; pkyziv= at@alum.mit.edu; clue@ietf.org
Subject: Re: Can CLUE signaling help reduce size of SDP?<= /span>

 

Hi all,= and happy new year!

My apol= ogies for this late reply, and thanks to Mark for reminding me.<= /span>

Yes, th= e language regarding the potential of reducing the SDP size through informa= tion gathered in the CLUE message exchange was originally from me.  It= stems from a time when we were considering (had agreed on?  At least in principle?  I don=92t recall=85) a = multiphase negotiation: 1) set-up CLUE channel, 2) negotiate (over the CLUE= channel, in a fashion similar to O/A) parameters that included parameters = traditionally negotiated over SDP using the much richer XML-based CLUE syntax, and 3) only then pro-forma =93negotiate=94 v= ia SDP O/A with the side effect of setting up the media.  A few years = ago, that line of thought was popular.  Personally, I still find it se= nsible, given the limitations and awkwardness of SDP.  But it=92s not how CLUE works today, as far as I understand = it.

Paul=92= s comments below sound sensible to me, but I=92m not sufficiently well vers= ed in CLUE and O/A to assert correctness or lack thereof.=

Regards= ,

Stephan=

&n= bsp;

&n= bsp;

From: <Duckworth>, "Duckworth, Mark" <= Mark.Duckworth@polycom.com>
Date: Monday, December 22, 2014 at 14:10
To: Paul Kyzivat <pkyziv= at@alum.mit.edu>, CLUE <clue@iet= f.org>, Stephan Wenger <stewe@= stewe.org>
Subject: Can CLUE signaling help reduce size of SDP?

&n= bsp;

From Paul=92s comments o= n the framework:

 =

> Section 5:<= /o:p>

>

> I'm struggling t= o understand the following paragraph:

>

>   &nbs= p; Second, it MAY, but is not necessarily REQUIRED to, use the

>   &nbs= p; information provided to tailor the SDP it is going to send during

>   &nbs= p; the following SIP offer/answer exchange, and its reaction to SDP it=

>   &nbs= p; receives in that step.  It is often a sensible implementation<= o:p>

>   &nbs= p; choice to do so, as the representation of the media information

>   &nbs= p; conveyed over the CLUE channel can dramatically cut down on the

>   &nbs= p; size of SDP messages used in the O/A exchange that follows.

>   &nbs= p; Spatial relationships associated with the Media can be included in<= o:p>

>   &nbs= p; the Advertisement, and it is often sensible for the Media Consumer<= o:p>

>   &nbs= p; to take those spatial relationships into account when tailoring the=

>   &nbs= p; SDP.

>

> This seems to me= to say that the consumer can use the advertisement to

> reduce the size = of the sdp, which isn't really true. I think the problem<= /p>

> is that this tex= t doesn't distinguish between what is done by providers

> and consumers.

>

> For a provider, = it may well be infeasible to send SDP covering every

> encoding in the = advertisement. It could potentially reduce the size of

> SDP to a more ma= nageable size by only offering those encodings that are

> configured. BUT,= as we have things structured now a consumer needs to

> see the encoding= s in the SDP to decide what to configure. So this

> potential can't = be realized.

>

> For a consumer t= he potential is not to reduce the size of SDP, but

> rather to reduce= the number of encodings it must set up resources to

> receive. It prob= ably doesn't want to receive encodings that it doesn't

> intend to use. I= think this is the key point to make in this paragraph.

>

> (These comments = also apply the the following paragraph.)

 =

I thought I understood t= his idea of reducing the SDP size, but now I

can=92t recall the detai= ls of that.  I think Stephan wrote these paragraphs.=

 =

Stephan, can you explain= what the intent was here?

 =

Thanks,
Mark

 =

--_000_D0D46E8F4E52Cstewesteweorg_-- From nobody Thu Jan 8 17:29:20 2015 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 8D0D21A7001 for ; Thu, 8 Jan 2015 17:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMawfQDoulWB for ; Thu, 8 Jan 2015 17:29:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3571A6FE9 for ; Thu, 8 Jan 2015 17:29:15 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Fri, 9 Jan 2015 01:28:51 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Fri, 9 Jan 2015 01:28:51 +0000 From: Stephan Wenger To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] CLUE framework, security consideration section, level of mandation Thread-Index: AQHQKUMbkgW5TlAA8EuhIA6D3OnVKpyyxNGAgAQF4RCAAAiWAP//qz+A Date: Fri, 9 Jan 2015 01:28:51 +0000 Message-ID: References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> <54AB246C.3030204@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6718@CRPMBOXPRD08.polycom.com> <54AF055A.4090200@nteczone.com> In-Reply-To: <54AF055A.4090200@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-dmarcaction: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 04519BA941 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(189002)(24454002)(377454003)(199003)(164054003)(13464003)(57704003)(51704005)(99286002)(92566001)(77156002)(62966003)(36756003)(2950100001)(106116001)(2900100001)(105586002)(107886001)(68736005)(107046002)(50986999)(76176999)(54356999)(106356001)(93886004)(102836002)(15975445007)(87936001)(4396001)(19580405001)(19580395003)(99396003)(31966008)(97736003)(64706001)(66066001)(120916001)(21056001)(561944003)(40100003)(2501002)(20776003)(86362001)(2656002)(101416001)(122556002)(46102003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2015 01:28:51.4898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 09 Jan 2015 01:29:18 -0000 RmluZS4NClN0ZXBoYW4NCg0KT24gMS84LzE1LCAxNDozMSwgIkNocmlzdGlhbiBHcm92ZXMiIDxD aHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbT4gd3JvdGU6DQoNCj5IZWxsbyBNYXJrLA0KPg0K PlNvdW5kcyBnb29kLg0KPg0KPkNocmlzdGlhbg0KPg0KPk9uIDkvMDEvMjAxNSA5OjA0IEFNLCBE dWNrd29ydGgsIE1hcmsgd3JvdGU6DQo+PiBJIGFncmVlIHdpdGggQ2hyaXN0aWFuLiAgU28gdGhl IHByb3Bvc2FsIGlzIHRvIGNoYW5nZSB0aGUgZmlyc3QgU0hPVUxEDQo+PnRvIE1VU1QsIGFuZCBk ZWxldGUgdGhlIGxhc3QgcGFydCBvZiB0aGUgc2VudGVuY2UuICBTbyB0aGUgbmV3IHRleHQNCj4+ d291bGQgYmU6DQo+Pg0KPj4gT25lIG90aGVyIGltcG9ydGFudCBjb25zaWRlcmF0aW9uIGZvciB0 aGUgaW5mb3JtYXRpb24gaW4gdGhlIHhDYXJkIGFzDQo+PndlbGwgYXMgdGhlIGRlc2NyaXB0aW9u IGZpZWxkIGluIHRoZSBNZWRpYSBDYXB0dXJlIGFuZCBDYXB0dXJlIFNjZW5lDQo+PlZpZXcgYXR0 cmlidXRlcyBpcyB0aGF0IHdoaWxlIHRoZSBlbmRwb2ludHMgaW52b2x2ZWQgaW4gdGhlIHNlc3Np b24gaGF2ZQ0KPj5iZWVuIGF1dGhlbnRpY2F0ZWQsIHRoZXJlIGlzIG5vIGFzc3VyYW5jZSB0aGF0 IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUNCj4+eENhcmQgb3IgZGVzY3JpcHRpb24gZmllbGRzIGlz IGF1dGhlbnRpYy4gIFRodXMsIHRoaXMgaW5mb3JtYXRpb24gTVVTVA0KPj5OT1QgYmUgdXNlZCB0 byBtYWtlIGFueSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucy4NCj4+DQo+PiBNYXJrDQo+Pg0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogY2x1ZSBbbWFpbHRvOmNsdWUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN0ZXBoYW4gV2VuZ2VyDQo+Pj4gU2VudDog VHVlc2RheSwgSmFudWFyeSAwNiwgMjAxNSAxMTozNSBBTQ0KPj4+IFRvOiBDaHJpc3RpYW4gR3Jv dmVzOyBjbHVlQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtjbHVlXSBDTFVFIGZyYW1ld29y aywgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLA0KPj4+bGV2ZWwgb2YNCj4+PiBtYW5k YXRpb24NCj4+Pg0KPj4+IEhpIENocmlzdGlhbiwNCj4+PiBUaGUgb25seSBwcmFjdGljYWwgY29u c2VxdWVuY2UgSSBjYW4gZW52aXNpb24gaXMgbGVzcyBub2lzZSBkdXJpbmcgdGhlDQo+Pj4gYXBw cm92YWwgcHJvY2VzcyBmcm9tIHRoZSBzZWN1cml0eSBjYW1wLiAgT2YgY291cnNlLCB0aGF0qfZz IGFsbCBJIGNhbg0KPj4+IGVudmlzaW9uIGZyb20gQU5ZIG5vcm1hdGl2ZSByZXF1aXJlbWVudCBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbg0KPj4+IHNlY3Rpb24tLWF0IGxlYXN0IGluIG15 IGZpZWxkIG9mIHdvcmssIHN1Y2ggcmVxdWlyZW1lbnRzIGhhdmUgYmVlbg0KPj4+IHJlZ3VsYXJs eSBpZ25vcmVkIGJ5IGluZHVzdHJ5IHdoZW4gY29udmVuaWVudC4NCj4+PiBCZWluZyBhIGJpdCBs ZXNzIHNhcmNhc3RpYywgeW91ciBsb2dpYyBzZWVtcyB0byBiZSBjb3JyZWN0LCBhbmQgdGhlDQo+ Pj5zZWNvbmQNCj4+PiBwYXJ0IG9mIHRoZSBzZW50ZW5jZSBtYXkgdGhlcmVmb3JlIG5vdCBiZSBu ZWVkZWQuICBBbHRob3VnaCBJIHZhZ3VlbHkNCj4+PiByZW1lbWJlciBoYXZpbmcgc2VlbiBhIHZl cnkgc2ltaWxhciBmb3JtdWxhdGlvbiBiZWZvcmUgaW4gYSBkaWZmZXJlbnQNCj4+PiBjb250ZXh0 LiAgTWFyeSwgaXMgdGhpcyB0ZXh0IGZyb20geW91PyAgV2hlcmUgZGlkIHRoZSBmb3JtdWxhdGlv biBjb21lDQo+Pj4gZnJvbT8NCj4+PiBUaGFua3MsDQo+Pj4gU3RlcGhhbg0KPj4+DQo+Pj4NCj4+ PiBPbiAxLzUvMTUsIDE1OjU1LCAiQ2hyaXN0aWFuIEdyb3ZlcyIgPENocmlzdGlhbi5Hcm92ZXNA bnRlY3pvbmUuY29tPg0KPj4+IHdyb3RlOg0KPj4+DQo+Pj4+IEhlbGxvLA0KPj4+Pg0KPj4+PiBX aGF0IGl0IGlzIHRoZSBwcmFjdGljYWwgcmVzdWx0IG9mIHRoZSBzZWNvbmQgIm11c3QiLCBpLmUu ICJhbmQgdGhlDQo+Pj4+IHBhcnRpY2lwYW50cyBpbiB0aGUgc2Vzc2lvbnMgTVVTVCBiZSBtYWRl IGF3YXJlIG9mIHRoaXMuIj8gIERvZXMgdGhpcw0KPj4+PiBtZWFuIHRoZXJlJ3MgYSBsZWdhbCBk aXNjbGFpbWVyIG9uIHRoZSB3aW5kb3cgc2F5aW5nIHRoYXQgdGhlDQo+Pj4+IHBhcnRpY2lwYW50 cyBtYXkgbm90IGJlIHRob3NlIHlvdSBleHBlY3Q/IERvIHdlIG5lZWQgdGhlIHNlY29uZCBwYXJ0 DQo+Pj4+b2YNCj4+Pj4gdGhlIHNlbnRlbmNlIHBlcnRhaW5pbmcgdG8gbm90aWZpY2F0aW9uIGlm IHdlIHNheSB0aGF0IENMVUUNCj4+Pj5pbmZvcm1hdGlvbg0KPj4+PiBNVVNUIG5vdCBiZSB1c2Vk IGZvciBhdXRob3JpemF0aW9uPw0KPj4+Pg0KPj4+PiBSZWdhcmRzLCBDaHJpc3RpYW4NCj4+Pj4N Cj4+Pj4gT24gMjkvMTIvMjAxNCAxMDowMyBQTSwgUm9uaSBFdmVuIHdyb3RlOg0KPj4+Pj4gSGks DQo+Pj4+Pg0KPj4+Pj4gT0sgd2l0aCB0aGlzIGNoYW5nZQ0KPj4+Pj4NCj4+Pj4+IFJvbmkgRXZl bg0KPj4+Pj4NCj4+Pj4+IEFzIGluZGl2aWR1YWwNCj4+Pj4+DQo+Pj4+PiAqRnJvbToqY2x1ZSBb bWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqU3RlcGhhbg0KPj4+ IFdlbmdlcg0KPj4+Pj4gKlNlbnQ6KiAyOSBEZWNlbWJlciwgMjAxNCA0OjUyIEFNDQo+Pj4+PiAq VG86KiBDTFVFDQo+Pj4+PiAqU3ViamVjdDoqIFtjbHVlXSBDTFVFIGZyYW1ld29yaywgc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLA0KPj4+Pj4gbGV2ZWwgb2YgbWFuZGF0aW9uDQo+Pj4+ Pg0KPj4+Pj4gSGksDQo+Pj4+Pg0KPj4+Pj4gTWFyayBhbmQgSSBhcmUgZWRpdGluZyB0aGUgZnJh bWV3b3JrIGRvY3VtZW50IHRvIGFkZHJlc3MgY29tbWVudHMuDQo+Pj4+Pg0KPj4+Pj4gVGhpcyBp cyB3aXRoIHJlZmVyZW5jZSB0byBteSByZXZpZXcsIGRhdGVkIDEyLzE2LzIwMTQsIGFuZA0KPj4+ Pj4gc3BlY2lmaWNhbGx5IHBvaW50IDkgdGhlcmVpbiwgcmVwcm9kdWNlZCBhcyBmb2xsb3dzOg0K Pj4+Pj4NCj4+Pj4+IDkuIFBhZ2UgNzAsIGZpcnN0IHBhcmFncmFwaHMuICBUaGVyZSBhcmUgdHdv IHVucXVhbGlmaWVkIKn4U0hPVUxEqfcNCj4+Pj4+IHN0YXRlbWVudHMuICBJbiB0aGUgc3Bpcml0 IG9mIGZhc3QgZG9jIGFwcHJvdmFsLCBJIHdvdWxkbqn2dCBvYmplY3QgaWYNCj4+Pj4+IHRob3Nl IHdlcmUgY2hhbmdlZCB0byCp+E1VU1Sp9y4gIEkgZG9uqfZ0IHJlY2FsbCB0aGF0IHdlIGRpc2N1 c3NlZCB0aGVzZQ0KPj4+Pj4gcG9pbnRzIGJlZm9yZSwgYnV0IEkgY291bGQgZWFzaWx5IGhhdmUg bWlzc2VkIHRoYXQgZGlzY3Vzc2lvbi4NCj4+Pj4+DQo+Pj4+PiBVbmxlc3Mgc29tZW9uZSBvYmpl Y3RzIHRoZSB0d28gU0hPVUxEIHN0YXRlbWVudHMgd2lsbCBiZSByZXBsYWNlZA0KPj4+IHdpdGgN Cj4+Pj4+IE1VU1QuICBUaGUgbW9kaWZpZWQgcGFyYWdyYXBoIGluIG1hcmt1cCBpcyBzaG93biBi ZWxvdyAoYWxzbw0KPj4+Pj4gYWRkcmVzc2luZyBjb21tZW50IDggb2YgbXkgcmV2aWV3LCBidXQg dGhhdKn2cyBhbiBlZGl0b3JpYWwgY2hhbmdlIGFuZA0KPj4+Pj4gc2hvdWxkIGJlIHVuY29udHJv dmVyc2lhbCkuICBTb3JyeSBmb3IgdGhlIG1lc3N5IGZvcm1hdHRpbmcuDQo+Pj4+Pg0KPj4+Pj4g SSBzdWdnZXN0IGEgZGVhZGxpbmUgb2YgSmFudWFyeSA5LCAyMDE1LCBidXQgZG8gc28gd2l0aG91 dCBjaGVja2luZw0KPj4+Pj4gd2l0aCB0aGUgY2hhaXJzPHdobyBhcmUgb2YgY291cnNlIGZyZWUg dG8gc2V0IGEgZGlmZmVyZW50IGRhdGUgaWYNCj4+Pj4+dGhleQ0KPj4+Pj4gY2hvb3NlIHNvLg0K Pj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+Pj4gU3RlcGhhbg0KPj4+Pj4NCj4+Pj4+ ICAgICAgQSBzZXBhcmF0ZSBkYXRhIGNoYW5uZWwgaXMgZXN0YWJsaXNoZWQgdG8gdHJhbnNwb3J0 IHRoZSBDTFVFDQo+Pj4+PiAgICAgIHByb3RvY29sIG1lc3NhZ2VzLiBUaGUgY29udGVudHMgb2Yg dGhlIENMVUUgcHJvdG9jb2wgbWVzc2FnZXMNCj4+Pj4+YXJlDQo+Pj4+PiAgICAgIGJhc2VkIG9u IGluZm9ybWF0aW9uIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudCwgd2hpY2ggaXMNCj4+Pj4+ ICAgICAgcmVwcmVzZW50ZWQgYnkgYW4gWE1MIHNjaGVtYSBmb3IgdGhpcyBpbmZvcm1hdGlvbiBk ZWZpbmVkIGluIHRoZQ0KPj4+Pj4gICAgICBDTFVFIGRhdGEgbW9kZWwgW3JlZl0uX1RoZSBDTFVF IGRhdGEgbW9kZWwNCj4+Pj4+IFtJLUQuaWV0Zi1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hXSBkZWZp bmVzIHRocm91Z2ggYW4gWE1MIHNjaGVtYSB0aGUNCj4+Pj4+IHN5bnRheCB0byBiZSB1c2VkLl8g ICBTb21lIG9mIHRoZSBpbmZvcm1hdGlvbiB3aGljaCBjb3VsZCBwb3NzaWJseQ0KPj4+Pj4gaW50 cm9kdWNlIHByaXZhY3kgY29uY2VybnMgaXMgdGhlIHhDYXJkIGluZm9ybWF0aW9uIGFzIGRlc2Ny aWJlZCBpbg0KPj4+Pj4gc2VjdGlvbiA3LjEuMS4xMS4gIEluIGFkZGl0aW9uLCB0aGUgKHRleHQp DQo+Pj4+PiAgICAgIGRlc2NyaXB0aW9uIGZpZWxkIGluIHRoZSBNZWRpYSBDYXB0dXJlIGF0dHJp YnV0ZSAoc2VjdGlvbg0KPj4+Pj43LjEuMS43KQ0KPj4+Pj4gICAgICBjb3VsZCBwb3NzaWJseSBy ZXZlYWwgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIG9yIHNwZWNpZmljDQo+Pj4+PiAgICAgIGlkZW50 aXRpZXMuIFRoZSBzYW1lIHdvdWxkIGJlIHRydWUgZm9yIHRoZSBkZXNjcmlwdGlvbnMgaW4gdGhl DQo+Pj4+PiAgICAgIENhcHR1cmUgU2NlbmUgKHNlY3Rpb24gNy4zLjEpIGFuZCBDYXB0dXJlIFNj ZW5lIFZpZXcgKDcuMy4yKQ0KPj4+Pj4gICAgICBhdHRyaWJ1dGVzLiAgIE9uZSBvdGhlciBpbXBv cnRhbnQgY29uc2lkZXJhdGlvbiBmb3IgdGhlDQo+Pj4+PiAgICAgIGluZm9ybWF0aW9uIGluIHRo ZSB4Q2FyZCBhcyB3ZWxsIGFzIHRoZSBkZXNjcmlwdGlvbiBmaWVsZCBpbiB0aGUNCj4+Pj4+ICAg ICAgTWVkaWEgQ2FwdHVyZSBhbmQgQ2FwdHVyZSBTY2VuZSBWaWV3IGF0dHJpYnV0ZXMgaXMgdGhh dCB3aGlsZQ0KPj4+Pj50aGUNCj4+Pj4+ICAgICAgZW5kcG9pbnRzIGludm9sdmVkIGluIHRoZSBz ZXNzaW9uIGhhdmUgYmVlbiBhdXRoZW50aWNhdGVkLCB0aGVyZQ0KPj4+Pj4gICAgICBpcyBubyBh c3N1cmFuY2UgdGhhdCB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIHhDYXJkIG9yIGRlc2NyaXB0aW9u DQo+Pj4+PiAgICAgIGZpZWxkcyBpcyBhdXRoZW50aWMuICBUaHVzLCB0aGlzIGluZm9ybWF0aW9u U0hPVUxEICBfTVVTVF8gIG5vdA0KPj4+Pj5iZQ0KPj4+Pj4gdXNlZCB0bw0KPj4+Pj4gICAgICBt YWtlIGFueSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucyBhbmQgdGhlIHBhcnRpY2lwYW50cyBpbiB0 aGUNCj4+Pj4+ICAgICAgc2Vzc2lvbnNTSE9VTEQgIF9NVVNUXyAgYmUgbWFkZSBhd2FyZSBvZiB0 aGlzLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IGNsdWVAaWV0 Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBjbHVlIG1haWxpbmcgbGlzdA0KPj4+PiBjbHVlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4+PiBj bHVlQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j bHVlDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5jbHVlIG1haWxpbmcgbGlzdA0KPmNsdWVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K From nobody Fri Jan 9 08:41:34 2015 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 144491A897C for ; Fri, 9 Jan 2015 08:41:24 -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 7l0YY4-7rjVb for ; Fri, 9 Jan 2015 08:41:22 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5871A87EE for ; Fri, 9 Jan 2015 08:41:22 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with comcast id dsd81p0082VvR6D01shMFh; Fri, 09 Jan 2015 16:41:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id dshM1p0013Ge9ey01shMd7; Fri, 09 Jan 2015 16:41:21 +0000 Message-ID: <54B004B0.5030907@alum.mit.edu> Date: Fri, 09 Jan 2015 11:41:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6714@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420821681; bh=Z6zfXGgpnqrmyL3SwffULfQ/E5PKrLnxYg9q0d8OTXk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=t9ecUsr+zfqFoS9X1b8aNQwOj6nfHr3xCVHDc8plx9+fXqejTHZxOF5K+3ZqIhz84 fzG2ZRy3F1VH1/J4whG4OaCtfqyDjc/G6b/hvrlStOqChRFKS0b3wWU6Qj2RP8y89p 8C5WNwmAlQ5U8UxYsIaDqbJ0y9UzwWUbe8tdDgRvqCUiMvFth/71iFT+yQWzCfZ/QZ JEIs4/O5SKHs8a4T53LeQEEjwFLftrDoTeDQ8UL0oftqwuCSCd0xvscFFbb+PnBhAL hxVbTHds7SXzglVj1K+gA7EmF6Ksf8q0es0OsyYWZ3VMRKnpxzFKV7U3Y9AOvfkY8Z S/6gXoDJAZhJA== Archived-At: Subject: Re: [clue] possible values for Person Type attribute 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, 09 Jan 2015 16:41:25 -0000 This sounds good to me. On 1/8/15 4:59 PM, Duckworth, Mark wrote: > There is a minor mismatch between framework and data model regarding the > “person type” attribute for a media capture. I have a proposal to align > them. > > These are the possible types listed in the framework: > > ·Chairman - the person responsible for running the conference according > to the agenda. > > ·Vice-Chairman - the person responsible for assisting the chairman in > running the meeting. > > ·Minute Taker - the person responsible for recording the minutes of the > conference. > > ·Member - the person has no particular responsibilities with respect to > running the meeting. > > ·Presenter - the person is scheduled on the agenda to make a > presentation in the meeting. Note: This is not related to any "active > speaker" functionality. > > ·Translator - the person is providing some form of translation or > commentary in the meeting. > > ·Timekeeper - the person is responsible for maintaining the meeting > schedule. > > Stephan proposed adding: > > ·Observer – a Member without the right to influence the discussion. > > These are the types listed in the data model: > > > > > > > > > > > > > > > > Looks like attendee is supposed to be the same as member. > > To make these consistent, I propose: > > ·in the framework, change the term “member” to “attendee” > > ·Accept Stephan’s proposal, and add “observer” to the data model and > framework > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Jan 9 09:18:15 2015 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 A76931A8A4E for ; Fri, 9 Jan 2015 09:18:12 -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 FH8yyMi7zuIc for ; Fri, 9 Jan 2015 09:18:11 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DC91A8A4D for ; Fri, 9 Jan 2015 09:18:10 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-02v.sys.comcast.net with comcast id dtJ41p00957bBgG01tJAdE; Fri, 09 Jan 2015 17:18:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id dtJ91p00K3Ge9ey01tJ9eQ; Fri, 09 Jan 2015 17:18:10 +0000 Message-ID: <54B00804.1000107@alum.mit.edu> Date: Fri, 09 Jan 2015 11:55:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <54AF136F.3010108@nteczone.com> In-Reply-To: <54AF136F.3010108@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420823890; bh=rit0XyifmN85SrBvwH0wP/bCUmnX2XhKH0CTtW/wPfw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=URLQFXfnzztOKnWWZ/2/gEYASxBRGZ9Y5dkM/Cdj02KMpO7UkvEQI/mNH75FNr53j XxqYg42/CRlemsOyNknqOdQPGyHL4+XuRSMjk1SpNZQ/2jyqxLLhBrFy2bxWMIcHrD Ob5VJqQOMyQPsjortSJIqowD4MGuLyf40q1WJNTgGoa2V4N+OT87ee1HtYPArr9NPZ nG7RyAqr5mI5Aq8UuS6SZD2wYNkEVGEx63cvGVVvVWsmve48QEUHhsNlxLbOuJ1W9F XJ1SgpIfCcVSO1vdpFN2+230KeWn9cjTfuxFJSLlpStDL6EmTIvzBNT408OZPp6MoK lMiGSN8kNjxqA== Archived-At: Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 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, 09 Jan 2015 17:18:12 -0000 On 1/8/15 6:31 PM, Christian Groves wrote: > Hello Christer, > > In draft-ietf-clue-datachannel-05 it says that the sctp-port is > optional, i.e. > > 3.2.1.2. SDP sctp-port Attribute > > As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute > value is set to the SCTP port of the SCTPoDTLS association. > > NOTE: Usage of the SDP sctp-port attribute is optional. As defined > in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then > the default value is 5000. > > However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. That is a new change - one I was not in favor of. :-( > BTW clause > 4.5 in the draft should probably also be updated to add a=sctp-port > because it is mandatory. > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Jan 9 09:20:13 2015 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 C28251A8A4E for ; Fri, 9 Jan 2015 09:20:10 -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 yU6Ny4_Wgz1q for ; Fri, 9 Jan 2015 09:20:08 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4FB1A8A79 for ; Fri, 9 Jan 2015 09:20:07 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-05v.sys.comcast.net with comcast id dtK61p00354zqzk01tL7m6; Fri, 09 Jan 2015 17:20:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id dtL61p00H3Ge9ey01tL6n1; Fri, 09 Jan 2015 17:20:07 +0000 Message-ID: <54B00802.7020601@alum.mit.edu> Date: Fri, 09 Jan 2015 11:55:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.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=q20140121; t=1420824007; bh=ZBxAl6gj9x8+Vrgl0WOoti1YIaNSR/PZdpvRuGHqeLI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hQ4zhdf5VTHlx9P8PZNkRZw+T0WY+yxQxi5h8JXHreoj+xCyt+DCD2UurVejsAEea mM8fppd9wv96l7otlZnaVQESMi2TKFXOgB9PQQaCdNWwGbgTh91bFyxzCv8Ky31J0j I8FpZPahhTTXXAFy5xy7I60Yx+u9AaJYaVSKATpyLNcmcJZ3lHCY5mptS2Vpc4tKgk kBRjSB1hX0tjIweSGZQ+ccMbMSKmTSdKWJ2y8TsCpTCDQbuXNk52q92mj9+YtVdA7d P0m1i/UFGuE8QO2q6jw+fm7rF5ktaXbR3SbnPdskRQVttASZjlfEc7ODcr3M/2jeNt 5FAunYUgjPqPg== Archived-At: Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 09 Jan 2015 17:20:11 -0000 On 1/8/15 5:35 PM, Duckworth, Mark wrote: > I see Paul and Rob agreeing with the proposal that says the Provider should not be required to honor a request in a Configure message to use only specific Captures in an MCC. Christian prefers to add an attribute the Provider can set, telling the Consumer whether or not it will accept such requests. > > Either way is okay with me. The main thing is not to force the provider to accept such subsetting, since it could prevent important implementation approaches. But then there needs to be clarification of what is to happen when a new source is being added to the MCC by the provider. If the consumer has selected a subset, does that mean it won't get the new source until it receives a new advertisement that mentions it and the consumer has updated the config to select it? Thanks, Paul > Any further discussion? How do we choose which way to go? > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Monday, January 05, 2015 7:15 PM >> To: clue@ietf.org >> Subject: Re: [clue] Consumer choosing subset of Captures from MCC >> >> Looking from a user perspective I have trouble with this change. If the >> MP provider receives an MCC and gives the participants a chance to >> choose the contributing captures then the user will expect to receive >> their choice. There's no feedback that their choice isn't allowed other >> than the captures they don't want appear in their media stream. They'll >> probably try to do the "choose" procedure again figuring that they did >> something wrong in the first place. >> >> So I don't support going from effectively a "MUST" to "a suggestion". I >> think the suggestion of adding an MCC attribute to indicate that a >> subset cannot be chosen is a more robust solution. >> >> Regards, Christian >> >> On 23/12/2014 4:23 AM, Duckworth, Mark wrote: >>> >>> We discussed this at the design team meeting last week. See Rob's >>> email from December 15. The issue is we think the Provider should not >>> be required to honor a request in a Configure message to use only >>> specific Captures in an MCC. Does the group agree with this proposed >>> change? >>> >>> Current text in the framework: >>> >>> - The Consumer may or may not choose to receive all the indicated >>> Captures. Therefore it can choose to receive a sub-set of Captures >>> indicated by the MCC. >>> >>> For example if the Consumer receives: >>> >>> MCC1(VC1,VC2,VC3){attributes} >>> >>> A Consumer could choose all the Captures within a MCCs however if the >>> Consumer determines that it doesn't want VC3 it can return >>> MCC1(VC1,VC2). If it wants all the individual Captures then it >>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>> advertisement does not reference any individual captures, then the >>> Consumer cannot choose what is included in the MCC, it is up to the >>> Provider to decide. >>> >>> Proposed new text in the framework: >>> >>> - The Consumer may or may not request to receive all the indicated >>> Captures. Therefore it can request to receive a sub-set of Captures >>> indicated by the MCC. >>> >>> For example if the Consumer receives an Advertisement with: >>> >>> MCC1(VC1,VC2,VC3){attributes} >>> >>> A Consumer could choose all the Captures within the MCC, however if >>> the Consumer determines that it doesn't want VC3 it can return >>> MCC1(VC1,VC2) in the Configure message. This is just a suggestion to >>> the Provider. The Provider MAY consider this suggestion when deciding >>> which Captures to include in the MCC Capture Encoding it sends to the >>> Consumer. If the Consumer wants all the individual Captures then it >>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>> advertisement does not reference any individual captures, then the >>> Consumer cannot choose what is included in the MCC, it is up to the >>> Provider to decide. >>> >>> Another possibility is to add a new MCC attribute in the >>> advertisement, so the Provider can indicate whether or not it will >>> accept requests asking for only a subset of captures in an MCC. >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Jan 9 09:26:00 2015 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 02BD01A8ACB for ; Fri, 9 Jan 2015 09:25: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 rrloKbF8USKv for ; Fri, 9 Jan 2015 09:25:54 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4C61A8A4D for ; Fri, 9 Jan 2015 09:25:54 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with comcast id dtRm1p0035AAYLo01tRuPn; Fri, 09 Jan 2015 17:25:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id dtRt1p00H3Ge9ey01tRt3z; Fri, 09 Jan 2015 17:25:54 +0000 Message-ID: <54B00F21.7010804@alum.mit.edu> Date: Fri, 09 Jan 2015 12:25:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephan Wenger , "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6721@CRPMBOXPRD08.polycom.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420824354; bh=hLKV9AZAW8J2GeyceT9hcsJtgBvgu5QvFP4HzPnMQwI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GpZzJfJrM1GPsdipYoqtChg2r4SWv4GdsBeSiy/qe6uuIe3rwkqnz1q/KPCGpcltO mIy6fYPT71ZneMRr2taj7O1NhKYxBkZ7xNpkyS1RRkcxEdPA0qi4/xtt90NICBFArP lj6fHUwxrso/p/889GxyBEGTXEek0+sXnA4xpuQT0Z8SUyKNEwFE2ERHfbvitE/zh3 b/y5Rt0KIvWk/pTU7VpfUNVclIGE5iaDOawTfnTINA1zBTSJt9lHhtiGePwNC5q9yr hd4xlOYK7CsHn1M4ZenswE6ehlfNB8nxpRoDOjNr1g4OByL5DrPxEuLXZO9qmJTkDI p8CRzU2zTrlmg== Archived-At: Subject: Re: [clue] Can CLUE signaling help reduce size of SDP? 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, 09 Jan 2015 17:25:57 -0000 +1 On 1/8/15 8:27 PM, Stephan Wenger wrote: > Good with me. > Stephan > > From: , "Duckworth, Mark" > > Date: Thursday, January 8, 2015 at 14:27 > To: Stephan Wenger >, Paul > Kyzivat >, CLUE > > > Subject: RE: Can CLUE signaling help reduce size of SDP? > > Okay, so based on Paul and Stephan’s comments, here is a proposal to > change those two paragraphs to remove the part about reducing SDP size, > and add Paul’s point about not wasting consumer resources. > > Proposed changed text: > > Also, the Consumer MAY use the information provided to tailor the SDP it > is going to send during any following SIP offer/answer exchange, and its > reaction to SDP it receives in that step. It is often a sensible > implementation choice to do so. Spatial relationships associated with > the Media can be included in the Advertisement, and it is often sensible > for the Media Consumer to take those spatial relationships into account > when tailoring the SDP. The Consumer can also limit the number of > encodings it must set up resources to receive, and not waste resources > on unwanted encodings, because it has the Provider’s Advertisement > information ahead of time to determine what it really wants to receive. > > This initial CLUE exchange is followed by an SDP offer/answer exchange > that not only establishes those aspects of the media that have not been > "negotiated" over CLUE, but has also the side effect of setting up the > media transmission itself, involving potentially security exchanges, > ICE, and whatnot. This step is plain vanilla SIP. > > Mark > > *From:*Stephan Wenger [mailto:stewe@stewe.org] > *Sent:* Thursday, January 08, 2015 12:47 PM > *To:* Duckworth, Mark; pkyzivat@alum.mit.edu > ; clue@ietf.org > *Subject:* Re: Can CLUE signaling help reduce size of SDP? > > Hi all, and happy new year! > > My apologies for this late reply, and thanks to Mark for reminding me. > > Yes, the language regarding the potential of reducing the SDP size > through information gathered in the CLUE message exchange was originally > from me. It stems from a time when we were considering (had agreed on? > At least in principle? I don’t recall…) a multiphase negotiation: 1) > set-up CLUE channel, 2) negotiate (over the CLUE channel, in a fashion > similar to O/A) parameters that included parameters traditionally > negotiated over SDP using the much richer XML-based CLUE syntax, and 3) > only then pro-forma “negotiate” via SDP O/A with the side effect of > setting up the media. A few years ago, that line of thought was > popular. Personally, I still find it sensible, given the limitations > and awkwardness of SDP. But it’s not how CLUE works today, as far as I > understand it. > > Paul’s comments below sound sensible to me, but I’m not sufficiently > well versed in CLUE and O/A to assert correctness or lack thereof. > > Regards, > > Stephan > > *From: *, "Duckworth, Mark" > > *Date: *Monday, December 22, 2014 at 14:10 > *To: *Paul Kyzivat >, CLUE >, Stephan Wenger > > *Subject: *Can CLUE signaling help reduce size of SDP? > > From Paul’s comments on the framework: > >> Section 5: > >> > >> I'm struggling to understand the following paragraph: > >> > >> Second, it MAY, but is not necessarily REQUIRED to, use the > >> information provided to tailor the SDP it is going to send during > >> the following SIP offer/answer exchange, and its reaction to SDP it > >> receives in that step. It is often a sensible implementation > >> choice to do so, as the representation of the media information > >> conveyed over the CLUE channel can dramatically cut down on the > >> size of SDP messages used in the O/A exchange that follows. > >> Spatial relationships associated with the Media can be included in > >> the Advertisement, and it is often sensible for the Media Consumer > >> to take those spatial relationships into account when tailoring the > >> SDP. > >> > >> This seems to me to say that the consumer can use the advertisement to > >> reduce the size of the sdp, which isn't really true. I think the problem > >> is that this text doesn't distinguish between what is done by providers > >> and consumers. > >> > >> For a provider, it may well be infeasible to send SDP covering every > >> encoding in the advertisement. It could potentially reduce the size of > >> SDP to a more manageable size by only offering those encodings that are > >> configured. BUT, as we have things structured now a consumer needs to > >> see the encodings in the SDP to decide what to configure. So this > >> potential can't be realized. > >> > >> For a consumer the potential is not to reduce the size of SDP, but > >> rather to reduce the number of encodings it must set up resources to > >> receive. It probably doesn't want to receive encodings that it doesn't > >> intend to use. I think this is the key point to make in this paragraph. > >> > >> (These comments also apply the the following paragraph.) > > I thought I understood this idea of reducing the SDP size, but now I > > can’t recall the details of that. I think Stephan wrote these paragraphs. > > Stephan, can you explain what the intent was here? > > Thanks, > Mark > From nobody Fri Jan 9 09:26:57 2015 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 21DDD1A8A4D for ; Fri, 9 Jan 2015 09:26:56 -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 6PueZvJtuXyy for ; Fri, 9 Jan 2015 09:26:53 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745BA1A8873 for ; Fri, 9 Jan 2015 09:26:53 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-09v.sys.comcast.net with comcast id dtSB1p00257bBgG01tStEZ; Fri, 09 Jan 2015 17:26:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e597:0:c0b3:218d:957e:af1a]) by resomta-po-13v.sys.comcast.net with comcast id dtSr1p0050goZN401tSrCx; Fri, 09 Jan 2015 17:26:52 +0000 Message-ID: <54B00F5A.5060005@alum.mit.edu> Date: Fri, 09 Jan 2015 12:26:50 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> <54AB246C.3030204@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6718@CRPMBOXPRD08.polycom.com> <54AF055A.4090200@nteczone.com> In-Reply-To: <54AF055A.4090200@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1420824413; bh=3j8U4lIAFDld7Uv3dRhgxmSWhaCnEWLp8N8yrR7L9kM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=on7nl5+M9STrhb7oKoiityExyDICDAgZnQtktyNzcgbkCx5JR6A8hjGLWSsrgid82 OSxK0TAv8aFkCpwSDEtDnbgcAjm+O2ycD3wlU6081lCNyHZCByQBw3AitBHEarSyVM OrB6H3gJv5R3PvcDQvsVFLu5aNcMFTHLPMyg2HQ/RjHv+mPI2GF7tfoexri8iN36Vc ShDPp21bqnVt98QyOLnqp+mH4HaoDpJOBC4qFY+KV+G5zC6/NNNl52pqNCOBeKJrR9 RxG6WnQ4qNR1oVuIma5yLolLyHov0eK6/qdZtuIYVICPo+gRwa32ywZOMMinD0ogJc 8yL10vdAQJXNQ== Archived-At: Subject: Re: [clue] CLUE framework, security consideration section, level of mandation 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, 09 Jan 2015 17:26:56 -0000 +1 On 1/8/15 5:31 PM, Christian Groves wrote: > Hello Mark, > > Sounds good. > > Christian > > On 9/01/2015 9:04 AM, Duckworth, Mark wrote: >> I agree with Christian. So the proposal is to change the first SHOULD >> to MUST, and delete the last part of the sentence. So the new text >> would be: >> >> One other important consideration for the information in the xCard as >> well as the description field in the Media Capture and Capture Scene >> View attributes is that while the endpoints involved in the session >> have been authenticated, there is no assurance that the information in >> the xCard or description fields is authentic. Thus, this information >> MUST NOT be used to make any authorization decisions. >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger >>> Sent: Tuesday, January 06, 2015 11:35 AM >>> To: Christian Groves; clue@ietf.org >>> Subject: Re: [clue] CLUE framework, security consideration section, >>> level of >>> mandation >>> >>> Hi Christian, >>> The only practical consequence I can envision is less noise during the >>> approval process from the security camp. Of course, thatąs all I can >>> envision from ANY normative requirement in the security consideration >>> section--at least in my field of work, such requirements have been >>> regularly ignored by industry when convenient. >>> Being a bit less sarcastic, your logic seems to be correct, and the >>> second >>> part of the sentence may therefore not be needed. Although I vaguely >>> remember having seen a very similar formulation before in a different >>> context. Mary, is this text from you? Where did the formulation come >>> from? >>> Thanks, >>> Stephan >>> >>> >>> On 1/5/15, 15:55, "Christian Groves" >>> wrote: >>> >>>> Hello, >>>> >>>> What it is the practical result of the second "must", i.e. "and the >>>> participants in the sessions MUST be made aware of this."? Does this >>>> mean there's a legal disclaimer on the window saying that the >>>> participants may not be those you expect? Do we need the second part of >>>> the sentence pertaining to notification if we say that CLUE information >>>> MUST not be used for authorization? >>>> >>>> Regards, Christian >>>> >>>> On 29/12/2014 10:03 PM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> OK with this change >>>>> >>>>> Roni Even >>>>> >>>>> As individual >>>>> >>>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan >>> Wenger >>>>> *Sent:* 29 December, 2014 4:52 AM >>>>> *To:* CLUE >>>>> *Subject:* [clue] CLUE framework, security consideration section, >>>>> level of mandation >>>>> >>>>> Hi, >>>>> >>>>> Mark and I are editing the framework document to address comments. >>>>> >>>>> This is with reference to my review, dated 12/16/2014, and >>>>> specifically point 9 therein, reproduced as follows: >>>>> >>>>> 9. Page 70, first paragraphs. There are two unqualified łSHOULD˛ >>>>> statements. In the spirit of fast doc approval, I wouldnąt object if >>>>> those were changed to łMUST˛. I donąt recall that we discussed these >>>>> points before, but I could easily have missed that discussion. >>>>> >>>>> Unless someone objects the two SHOULD statements will be replaced >>> with >>>>> MUST. The modified paragraph in markup is shown below (also >>>>> addressing comment 8 of my review, but thatąs an editorial change and >>>>> should be uncontroversial). Sorry for the messy formatting. >>>>> >>>>> I suggest a deadline of January 9, 2015, but do so without checking >>>>> with the chairs>>>> choose so. >>>>> >>>>> Regards, >>>>> >>>>> Stephan >>>>> >>>>> A separate data channel is established to transport the CLUE >>>>> protocol messages. The contents of the CLUE protocol messages are >>>>> based on information introduced in this document, which is >>>>> represented by an XML schema for this information defined in the >>>>> CLUE data model [ref]._The CLUE data model >>>>> [I-D.ietf-clue-data-model-schema] defines through an XML schema the >>>>> syntax to be used._ Some of the information which could possibly >>>>> introduce privacy concerns is the xCard information as described in >>>>> section 7.1.1.11. In addition, the (text) >>>>> description field in the Media Capture attribute (section >>>>> 7.1.1.7) >>>>> could possibly reveal sensitive information or specific >>>>> identities. The same would be true for the descriptions in the >>>>> Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) >>>>> attributes. One other important consideration for the >>>>> information in the xCard as well as the description field in the >>>>> Media Capture and Capture Scene View attributes is that while the >>>>> endpoints involved in the session have been authenticated, there >>>>> is no assurance that the information in the xCard or description >>>>> fields is authentic. Thus, this informationSHOULD _MUST_ >>>>> not be >>>>> used to >>>>> make any authorization decisions and the participants in the >>>>> sessionsSHOULD _MUST_ be made aware of this. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 nobody Sun Jan 11 21:31:37 2015 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 A0A571A8A50 for ; Sun, 11 Jan 2015 21:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vLXt2XfZK8H for ; Sun, 11 Jan 2015 21:31:33 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417011A8895 for ; Sun, 11 Jan 2015 21:31:33 -0800 (PST) Received: from ppp118-209-110-47.lns20.mel4.internode.on.net ([118.209.110.47]:53683 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YAXYt-0006dT-6o for clue@ietf.org; Mon, 12 Jan 2015 16:29:11 +1100 Message-ID: <54B35C32.90201@nteczone.com> Date: Mon, 12 Jan 2015 16:31:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.polycom.com> <54B00802.7020601@alum.mit.edu> In-Reply-To: <54B00802.7020601@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 12 Jan 2015 05:31:35 -0000 I agree its important not to force the provider to accept subsetting, that's why I think its important for the consumer to know whether the provider allows it or not. An MCC attribute would allow this. If a new source is added I would think it is handled like any other capture. The provider advertises it and if the consumer wants it then it should send a configure. Regards, Christian On 10/01/2015 3:55 AM, Paul Kyzivat wrote: > On 1/8/15 5:35 PM, Duckworth, Mark wrote: >> I see Paul and Rob agreeing with the proposal that says the Provider >> should not be required to honor a request in a Configure message to >> use only specific Captures in an MCC. Christian prefers to add an >> attribute the Provider can set, telling the Consumer whether or not >> it will accept such requests. >> >> Either way is okay with me. > > The main thing is not to force the provider to accept such subsetting, > since it could prevent important implementation approaches. > > But then there needs to be clarification of what is to happen when a > new source is being added to the MCC by the provider. If the consumer > has selected a subset, does that mean it won't get the new source > until it receives a new advertisement that mentions it and the > consumer has updated the config to select it? > > Thanks, > Paul > >> Any further discussion? How do we choose which way to go? >> >> Mark >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: Monday, January 05, 2015 7:15 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Consumer choosing subset of Captures from MCC >>> >>> Looking from a user perspective I have trouble with this change. If the >>> MP provider receives an MCC and gives the participants a chance to >>> choose the contributing captures then the user will expect to receive >>> their choice. There's no feedback that their choice isn't allowed other >>> than the captures they don't want appear in their media stream. They'll >>> probably try to do the "choose" procedure again figuring that they did >>> something wrong in the first place. >>> >>> So I don't support going from effectively a "MUST" to "a suggestion". I >>> think the suggestion of adding an MCC attribute to indicate that a >>> subset cannot be chosen is a more robust solution. >>> >>> Regards, Christian >>> >>> On 23/12/2014 4:23 AM, Duckworth, Mark wrote: >>>> >>>> We discussed this at the design team meeting last week. See Rob's >>>> email from December 15. The issue is we think the Provider should not >>>> be required to honor a request in a Configure message to use only >>>> specific Captures in an MCC. Does the group agree with this proposed >>>> change? >>>> >>>> Current text in the framework: >>>> >>>> - The Consumer may or may not choose to receive all the indicated >>>> Captures. Therefore it can choose to receive a sub-set of Captures >>>> indicated by the MCC. >>>> >>>> For example if the Consumer receives: >>>> >>>> MCC1(VC1,VC2,VC3){attributes} >>>> >>>> A Consumer could choose all the Captures within a MCCs however if the >>>> Consumer determines that it doesn't want VC3 it can return >>>> MCC1(VC1,VC2). If it wants all the individual Captures then it >>>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>>> advertisement does not reference any individual captures, then the >>>> Consumer cannot choose what is included in the MCC, it is up to the >>>> Provider to decide. >>>> >>>> Proposed new text in the framework: >>>> >>>> - The Consumer may or may not request to receive all the indicated >>>> Captures. Therefore it can request to receive a sub-set of Captures >>>> indicated by the MCC. >>>> >>>> For example if the Consumer receives an Advertisement with: >>>> >>>> MCC1(VC1,VC2,VC3){attributes} >>>> >>>> A Consumer could choose all the Captures within the MCC, however if >>>> the Consumer determines that it doesn't want VC3 it can return >>>> MCC1(VC1,VC2) in the Configure message. This is just a suggestion to >>>> the Provider. The Provider MAY consider this suggestion when deciding >>>> which Captures to include in the MCC Capture Encoding it sends to the >>>> Consumer. If the Consumer wants all the individual Captures then it >>>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>>> advertisement does not reference any individual captures, then the >>>> Consumer cannot choose what is included in the MCC, it is up to the >>>> Provider to decide. >>>> >>>> Another possibility is to add a new MCC attribute in the >>>> advertisement, so the Provider can indicate whether or not it will >>>> accept requests asking for only a subset of captures in an MCC. >>>> >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jan 12 05:50:06 2015 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 40C671A90CA for ; Mon, 12 Jan 2015 05:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSnXLlDFUJlZ for ; Mon, 12 Jan 2015 05:49:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17AE1A90EC for ; Mon, 12 Jan 2015 05:49:57 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-b1-54b3d1034a1d Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 99.55.04484.301D3B45; Mon, 12 Jan 2015 14:49:56 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 14:49:55 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] SCTP port in draft-ietf-clue-datachannel-05 Thread-Index: AQHQK5tZDy30wieS6UGfQ3LEj3AaYpy38i4AgASS4rA= Date: Mon, 12 Jan 2015 13:49:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6347A1@ESESSMB209.ericsson.se> References: <54AF136F.3010108@nteczone.com> <54B00804.1000107@alum.mit.edu> In-Reply-To: <54B00804.1000107@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjS7Lxc0hBpf3sFvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGzb1bmQp28VRcXX+LqYGxk6uLkZNDQsBE YtXmyWwQtpjEhXvrgWwuDiGBI4wS86/+ZodwljBKnFp0k7WLkYODTcBCovufNkiDiICnxI6P U5hBbGEBe4lla44zQcQdJM5N/g5lW0l8vL2FFcRmEVCVaD2wmhlkDK+Ar8TpVykgYSEBb4nd T6+AlXMK6EgcuLQCrJwR6J7vp9aAxZkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2IoSO8+2 M0PU60gs2P2JDcLWlli28DVYnFdAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWpyU m25kpJdalJlcXJyfp5eXWrKJERglB7f8NtjB+PK54yFGAQ5GJR5eg5WbQ4RYE8uKK3MPMUpz sCiJ8+Y5bAgREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFiSLHLC9f45lyydI3cb7Xy0PXj4 QwV0b/R/ZDjw0irywJ59tv08NaYvhASuG79qUI9bI37sz6QgbvU/0+4szWXsjXo+6/W7U1qM +ZeU9tx7+VQ98uRz4QWHjGS8psU4SyZ7Mtxf6j2beQ/XVudDh7NtEhy+c1qWXwnZvp5HhZHh 763HiUISi5RYijMSDbWYi4oTAckQVWxzAgAA Archived-At: Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 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, 12 Jan 2015 13:50:00 -0000 Hi, My understanding was that people did not want to define a default sctp-port= value. Personally I don't care - I just want to get the draft done. Anyway, that discussion belongs to MMUSIC. However, the CLUE documents stil= l need to be aligned with the latest MMUSIC draft. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 9. tammikuuta 2015 18:56 To: clue@ietf.org Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 On 1/8/15 6:31 PM, Christian Groves wrote: > Hello Christer, > > In draft-ietf-clue-datachannel-05 it says that the sctp-port is=20 > optional, i.e. > > 3.2.1.2. SDP sctp-port Attribute > > As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute > value is set to the SCTP port of the SCTPoDTLS association. > > NOTE: Usage of the SDP sctp-port attribute is optional. As defined > in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then > the default value is 5000. > > However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. That is a new change - one I was not in favor of. :-( > BTW clause > 4.5 in the draft should probably also be updated to add a=3Dsctp-port=20 > because it is mandatory. > > 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 nobody Mon Jan 12 06:52:34 2015 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 4C7DF1AC399 for ; Mon, 12 Jan 2015 06:52:32 -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 eRD6DKmiQcYN for ; Mon, 12 Jan 2015 06:52:30 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E6741AC3A7 for ; Mon, 12 Jan 2015 06:52:29 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-01v.sys.comcast.net with comcast id f2s51p0074s37d4012sU9c; Mon, 12 Jan 2015 14:52:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id f2sT1p00R3Ge9ey012sUB7; Mon, 12 Jan 2015 14:52:28 +0000 Message-ID: <54B3DFAB.4070502@alum.mit.edu> Date: Mon, 12 Jan 2015 09:52:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.polycom.com> <54B00802.7020601@alum.mit.edu> <54B35C32.90201@nteczone.com> In-Reply-To: <54B35C32.90201@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1421074348; bh=Jh+jr7AcFMkJoUlEUXQGXTc7wMG6S+fKLXmQ1xGclUY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D9FoYtZaY/HDVFpMqL8Sn6qunNyhmQcYHtsY8EaEEUMeawQo3BDGi9nXjv63AYklb vDTi5rBRafUbJ+ZsezvlMUbPP/gGmBnNBhxOys9Do/uCImasJ9cZf0Qry5SdKgK/OT uickuHbZxjZyU5sIDMRsAkrQQw4VfpFJGkma96IMQO7CStlcSf5uXDJc3fFVflN1Y7 UpCChKAjnxK1/1hQ6nWpny5aLptJM1TxxRYI42s+jXZkXliKKlcK8fWwJitNGWjkRF gqHeDFIQcYCs+AhRHuXWLpQqMSpz/3h/bD0r8HtsgkbiXIGdset9Njjk/KtaIZVqDB +oByA8AWWgd+g== Archived-At: Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 12 Jan 2015 14:52:32 -0000 On 1/12/15 12:31 AM, Christian Groves wrote: > I agree its important not to force the provider to accept subsetting, > that's why I think its important for the consumer to know whether the > provider allows it or not. An MCC attribute would allow this. > > If a new source is added I would think it is handled like any other > capture. The provider advertises it and if the consumer wants it then it > should send a configure. The problem here is timeliness. If you don't subset then you see the new source immediately. If you subset, then you miss the new source until you see the advertisement and configure it. I suppose one way to deal with that would be for the subset to be specified by listing those sources you *don't* want to receive. Thanks, Paul > Regards, Christian > > On 10/01/2015 3:55 AM, Paul Kyzivat wrote: >> On 1/8/15 5:35 PM, Duckworth, Mark wrote: >>> I see Paul and Rob agreeing with the proposal that says the Provider >>> should not be required to honor a request in a Configure message to >>> use only specific Captures in an MCC. Christian prefers to add an >>> attribute the Provider can set, telling the Consumer whether or not >>> it will accept such requests. >>> >>> Either way is okay with me. >> >> The main thing is not to force the provider to accept such subsetting, >> since it could prevent important implementation approaches. >> >> But then there needs to be clarification of what is to happen when a >> new source is being added to the MCC by the provider. If the consumer >> has selected a subset, does that mean it won't get the new source >> until it receives a new advertisement that mentions it and the >> consumer has updated the config to select it? >> >> Thanks, >> Paul >> >>> Any further discussion? How do we choose which way to go? >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>>> Sent: Monday, January 05, 2015 7:15 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Consumer choosing subset of Captures from MCC >>>> >>>> Looking from a user perspective I have trouble with this change. If the >>>> MP provider receives an MCC and gives the participants a chance to >>>> choose the contributing captures then the user will expect to receive >>>> their choice. There's no feedback that their choice isn't allowed other >>>> than the captures they don't want appear in their media stream. They'll >>>> probably try to do the "choose" procedure again figuring that they did >>>> something wrong in the first place. >>>> >>>> So I don't support going from effectively a "MUST" to "a suggestion". I >>>> think the suggestion of adding an MCC attribute to indicate that a >>>> subset cannot be chosen is a more robust solution. >>>> >>>> Regards, Christian >>>> >>>> On 23/12/2014 4:23 AM, Duckworth, Mark wrote: >>>>> >>>>> We discussed this at the design team meeting last week. See Rob's >>>>> email from December 15. The issue is we think the Provider should not >>>>> be required to honor a request in a Configure message to use only >>>>> specific Captures in an MCC. Does the group agree with this proposed >>>>> change? >>>>> >>>>> Current text in the framework: >>>>> >>>>> - The Consumer may or may not choose to receive all the indicated >>>>> Captures. Therefore it can choose to receive a sub-set of Captures >>>>> indicated by the MCC. >>>>> >>>>> For example if the Consumer receives: >>>>> >>>>> MCC1(VC1,VC2,VC3){attributes} >>>>> >>>>> A Consumer could choose all the Captures within a MCCs however if the >>>>> Consumer determines that it doesn't want VC3 it can return >>>>> MCC1(VC1,VC2). If it wants all the individual Captures then it >>>>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>>>> advertisement does not reference any individual captures, then the >>>>> Consumer cannot choose what is included in the MCC, it is up to the >>>>> Provider to decide. >>>>> >>>>> Proposed new text in the framework: >>>>> >>>>> - The Consumer may or may not request to receive all the indicated >>>>> Captures. Therefore it can request to receive a sub-set of Captures >>>>> indicated by the MCC. >>>>> >>>>> For example if the Consumer receives an Advertisement with: >>>>> >>>>> MCC1(VC1,VC2,VC3){attributes} >>>>> >>>>> A Consumer could choose all the Captures within the MCC, however if >>>>> the Consumer determines that it doesn't want VC3 it can return >>>>> MCC1(VC1,VC2) in the Configure message. This is just a suggestion to >>>>> the Provider. The Provider MAY consider this suggestion when deciding >>>>> which Captures to include in the MCC Capture Encoding it sends to the >>>>> Consumer. If the Consumer wants all the individual Captures then it >>>>> returns only the MCC identity (i.e. MCC1). If the MCC in the >>>>> advertisement does not reference any individual captures, then the >>>>> Consumer cannot choose what is included in the MCC, it is up to the >>>>> Provider to decide. >>>>> >>>>> Another possibility is to add a new MCC attribute in the >>>>> advertisement, so the Provider can indicate whether or not it will >>>>> accept requests asking for only a subset of captures in an MCC. >>>>> >>>>> Mark >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jan 12 08:50:43 2015 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 99DEA1ACD0E for ; Mon, 12 Jan 2015 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNrdXmOe7-cZ for ; Mon, 12 Jan 2015 08:50:36 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5C91AC3E4 for ; Mon, 12 Jan 2015 08:49:03 -0800 (PST) Received: from [216.82.254.19] by server-8.bemta-7.messagelabs.com id 47/DD-03121-EFAF3B45; Mon, 12 Jan 2015 16:49:02 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-96.messagelabs.com!1421081189!16965219!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22947 invoked from network); 12 Jan 2015 16:46:30 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 12 Jan 2015 16:46:30 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 12 Jan 2015 08:46:29 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" , "Christian Groves (Christian.Groves@nteczone.com)" Date: Mon, 12 Jan 2015 08:46:26 -0800 Thread-Topic: [clue] Consumer choosing subset of Captures from MCC Thread-Index: AdAud2eP5dixAoFoRGy6SS2CDymhIgADuMyQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF68EB@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> <54AB28EA.8040409@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6723@CRPMBOXPRD08.polycom.com> <54B00802.7020601@alum.mit.edu> <54B35C32.90201@nteczone.com> <54B3DFAB.4070502@alum.mit.edu> In-Reply-To: <54B3DFAB.4070502@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] Consumer choosing subset of Captures from MCC 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, 12 Jan 2015 16:50:39 -0000 Inline, my responses to Christian and Paul. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, January 12, 2015 9:52 AM > To: clue@ietf.org > Subject: Re: [clue] Consumer choosing subset of Captures from MCC >=20 > On 1/12/15 12:31 AM, Christian Groves wrote: > > I agree its important not to force the provider to accept subsetting, > > that's why I think its important for the consumer to know whether the > > provider allows it or not. An MCC attribute would allow this. [Duckworth, Mark] I suspect the group will not object to adding an attribut= e, so I will make a specific proposal to add text for this, in a separate emai= l. > > If a new source is added I would think it is handled like any other > > capture. The provider advertises it and if the consumer wants it then i= t > > should send a configure. >=20 > The problem here is timeliness. If you don't subset then you see the new > source immediately. If you subset, then you miss the new source until > you see the advertisement and configure it. [Duckworth, Mark] I agree with Christian, and I don't see timeliness as a problem here. If the Consumer asks for something specific, then that is what it gets, with no new additions, until it specifically changes what it asks for with another configure message. > I suppose one way to deal with that would be for the subset to be > specified by listing those sources you *don't* want to receive. >=20 > Thanks, > Paul >=20 > > Regards, Christian > > > > On 10/01/2015 3:55 AM, Paul Kyzivat wrote: > >> On 1/8/15 5:35 PM, Duckworth, Mark wrote: > >>> I see Paul and Rob agreeing with the proposal that says the Provider > >>> should not be required to honor a request in a Configure message to > >>> use only specific Captures in an MCC. Christian prefers to add an > >>> attribute the Provider can set, telling the Consumer whether or not > >>> it will accept such requests. > >>> > >>> Either way is okay with me. > >> > >> The main thing is not to force the provider to accept such subsetting, > >> since it could prevent important implementation approaches. > >> > >> But then there needs to be clarification of what is to happen when a > >> new source is being added to the MCC by the provider. If the consumer > >> has selected a subset, does that mean it won't get the new source > >> until it receives a new advertisement that mentions it and the > >> consumer has updated the config to select it? > >> > >> Thanks, > >> Paul > >> > >>> Any further discussion? How do we choose which way to go? > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > Groves > >>>> Sent: Monday, January 05, 2015 7:15 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] Consumer choosing subset of Captures from MCC > >>>> > >>>> Looking from a user perspective I have trouble with this change. If = the > >>>> MP provider receives an MCC and gives the participants a chance to > >>>> choose the contributing captures then the user will expect to receiv= e > >>>> their choice. There's no feedback that their choice isn't allowed ot= her > >>>> than the captures they don't want appear in their media stream. They= 'll > >>>> probably try to do the "choose" procedure again figuring that they d= id > >>>> something wrong in the first place. > >>>> > >>>> So I don't support going from effectively a "MUST" to "a suggestion"= . I > >>>> think the suggestion of adding an MCC attribute to indicate that a > >>>> subset cannot be chosen is a more robust solution. > >>>> > >>>> Regards, Christian > >>>> > >>>> On 23/12/2014 4:23 AM, Duckworth, Mark wrote: > >>>>> > >>>>> We discussed this at the design team meeting last week. See Rob's > >>>>> email from December 15. The issue is we think the Provider should > not > >>>>> be required to honor a request in a Configure message to use only > >>>>> specific Captures in an MCC. Does the group agree with this propose= d > >>>>> change? > >>>>> > >>>>> Current text in the framework: > >>>>> > >>>>> - The Consumer may or may not choose to receive all the indicated > >>>>> Captures. Therefore it can choose to receive a sub-set of Captures > >>>>> indicated by the MCC. > >>>>> > >>>>> For example if the Consumer receives: > >>>>> > >>>>> MCC1(VC1,VC2,VC3){attributes} > >>>>> > >>>>> A Consumer could choose all the Captures within a MCCs however if > the > >>>>> Consumer determines that it doesn't want VC3 it can return > >>>>> MCC1(VC1,VC2). If it wants all the individual Captures then it > >>>>> returns only the MCC identity (i.e. MCC1). If the MCC in the > >>>>> advertisement does not reference any individual captures, then the > >>>>> Consumer cannot choose what is included in the MCC, it is up to the > >>>>> Provider to decide. > >>>>> > >>>>> Proposed new text in the framework: > >>>>> > >>>>> - The Consumer may or may not request to receive all the indicated > >>>>> Captures. Therefore it can request to receive a sub-set of Capture= s > >>>>> indicated by the MCC. > >>>>> > >>>>> For example if the Consumer receives an Advertisement with: > >>>>> > >>>>> MCC1(VC1,VC2,VC3){attributes} > >>>>> > >>>>> A Consumer could choose all the Captures within the MCC, however if > >>>>> the Consumer determines that it doesn't want VC3 it can return > >>>>> MCC1(VC1,VC2) in the Configure message. This is just a suggestion t= o > >>>>> the Provider. The Provider MAY consider this suggestion when > deciding > >>>>> which Captures to include in the MCC Capture Encoding it sends to t= he > >>>>> Consumer. If the Consumer wants all the individual Captures then it > >>>>> returns only the MCC identity (i.e. MCC1). If the MCC in the > >>>>> advertisement does not reference any individual captures, then the > >>>>> Consumer cannot choose what is included in the MCC, it is up to the > >>>>> Provider to decide. > >>>>> > >>>>> Another possibility is to add a new MCC attribute in the > >>>>> advertisement, so the Provider can indicate whether or not it will > >>>>> accept requests asking for only a subset of captures in an MCC. > >>>>> > >>>>> Mark From nobody Fri Jan 16 14:51:33 2015 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 CE4561A8AD9 for ; Fri, 16 Jan 2015 14:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYByZHIiUQJL for ; Fri, 16 Jan 2015 14:51:29 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037BB1A8A12 for ; Fri, 16 Jan 2015 14:51:28 -0800 (PST) Received: from [216.82.254.19] by server-13.bemta-7.messagelabs.com id AC/A1-02788-0F599B45; Fri, 16 Jan 2015 22:51:28 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-96.messagelabs.com!1421448687!24663421!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28813 invoked from network); 16 Jan 2015 22:51:28 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-12.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jan 2015 22:51:28 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 16 Jan 2015 14:51:27 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 16 Jan 2015 14:51:25 -0800 Thread-Topic: MCC attribute Allow Subset Choice Thread-Index: AdAx3md8EJErYgc5SDq848IGlp0CLw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] MCC attribute Allow Subset Choice 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, 16 Jan 2015 22:51:31 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is proposed framework text changes for a new MCC attribute. Please co= mment. Add to section 7: 7.2.1.4. Allow Subset Choice The Allow Subset Choice MCC attribute is a boolean value, indicating whethe= r or not the Provider allows the Consumer to choose a specific subset of th= e Captures referenced by the MCC. If this attribute is true, and the MCC r= eferences other Captures, then the Consumer MAY select (in a Configure mess= age) a specific subset of those Captures to be included in the MCC. If thi= s attribute is false, or the MCC does not reference other Captures, then th= e Consumer MUST NOT select a subset. Change text in section 9: - If the MCC attribute Allow Subset Choice is true, then the Consumer may o= r may not choose to receive all the indicated Captures. It can choose to r= eceive a sub-set of Captures indicated by the MCC. For example if the Consumer receives: MCC1(VC1,VC2,VC3){attributes} A Consumer could choose all the Captures within a MCCs however if the Consu= mer determines that it doesn't want VC3 it can return MCC1(VC1,VC2). If it= wants all the individual Captures then it returns only the MCC identity (i= .e. MCC1). If the MCC in the advertisement does not reference any individu= al captures, or the Allow Subset Choice attribute is false, then the Consum= er cannot choose what is included in the MCC, it is up to the Provider to d= ecide. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is proposed= framework text changes for a new MCC attribute.  Please comment.=

 

Ad= d to section 7:

 

7.2.1.4. Allow Subset Choice

 

The Allow Subset Choice MC= C attribute is a boolean value, indicating whether or not the Provider allo= ws the Consumer to choose a specific subset of the Captures referenced by t= he MCC.  If this attribute is true, and the MCC references other Captu= res, then the Consumer MAY select (in a Configure message) a specific subse= t of those Captures to be included in the MCC.  If this attribute is f= alse, or the MCC does not reference other Captures, then the Consumer MUST = NOT select a subset.

 

Change text in section 9:

 

- If the MCC attribute A= llow Subset Choice is true, then the Consumer may or may not choose to rece= ive all the indicated Captures.  It can choose to receive a sub-set of= Captures indicated by the MCC.

&nb= sp;

For example if the Consumer receives:

        = MCC1(VC1,VC2,VC3){attributes}

 = ;

A Consumer could choose all the Captures wi= thin a MCCs however if the Consumer determines that it doesn't want VC3 it = can return MCC1(VC1,VC2).  If it wants all the individual Captures the= n it returns only the MCC identity (i.e. MCC1).  If the MCC in the adv= ertisement does not reference any individual captures, or the Allow Subset = Choice attribute is false, then the Consumer cannot choose what is included= in the MCC, it is up to the Provider to decide.

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1CRPMBOXPRD08p_-- From nobody Mon Jan 19 08:13:26 2015 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 90B2A1ACE2F for ; Mon, 19 Jan 2015 08:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtE9axC70pwb for ; Mon, 19 Jan 2015 08:13:24 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3408C1B2B0E for ; Mon, 19 Jan 2015 08:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6923; q=dns/txt; s=iport; t=1421683929; x=1422893529; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=bI2MBA9mrQ/S6KHLExGgwnASg1pLL50me0iqGvr6Q3s=; b=PSrMBTp0Xl8BdrloPlDcfxa/EO26SXRax1oZXsmWOw38S1w0Evri4mK2 IAClegBqdEmaRzGoCYVtatvtk+ZeFf/KNoG70SPEnoo/qRPPM1Os6TdIg 80H5Q+V+We+B/Yd/OKHeUjmf27Rt/v8+gWVZ9zGNjjAvg2SA/F1vBMlun w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYKAJgsvVStJssW/2dsb2JhbABSCYJDgRW0SgEBAQEBAQUBd5FHAQmFcQKBZQEBAQEBfYQNAQEEAQEBKkEKEQsYCRYPCQMCAQIBFTATBgIBAYgoDc8LAQEBAQEBAQMBAQEBAQEBFwSGBYkZYoQpBYx6inaBFIJ8gh+LeyKDbj4xgQMFgTsBAQE X-IronPort-AV: E=Sophos;i="5.09,427,1418083200"; d="scan'208,217";a="313816573" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 19 Jan 2015 16:12:07 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t0JGC1nV010734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 19 Jan 2015 16:12:07 GMT Message-ID: <54BD2CDB.8060308@cisco.com> Date: Mon, 19 Jan 2015 16:12:11 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> Content-Type: multipart/alternative; boundary="------------090107050702080406030600" X-Authenticated-User: rohanse2 Archived-At: Subject: Re: [clue] MCC attribute Allow Subset Choice 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, 19 Jan 2015 16:13:25 -0000 This is a multi-part message in MIME format. --------------090107050702080406030600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Mark, That looks good to me. Rob On 16/01/15 22:51, Duckworth, Mark wrote: > > Here is proposed framework text changes for a new MCC attribute. > Please comment. > > Add to section 7: > > 7.2.1.4. Allow Subset Choice > > The Allow Subset Choice MCC attribute is a boolean value, indicating > whether or not the Provider allows the Consumer to choose a specific > subset of the Captures referenced by the MCC. If this attribute is > true, and the MCC references other Captures, then the Consumer MAY > select (in a Configure message) a specific subset of those Captures to > be included in the MCC. If this attribute is false, or the MCC does > not reference other Captures, then the Consumer MUST NOT select a subset. > > Change text in section 9: > > - If the MCC attribute Allow Subset Choice is true, then the Consumer > may or may not choose to receive all the indicated Captures. It can > choose to receive a sub-set of Captures indicated by the MCC. > > For example if the Consumer receives: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within a MCCs however if the > Consumer determines that it doesn't want VC3 it can return > MCC1(VC1,VC2). If it wants all the individual Captures then it > returns only the MCC identity (i.e. MCC1). If the MCC in the > advertisement does not reference any individual captures, or the Allow > Subset Choice attribute is false, then the Consumer cannot choose what > is included in the MCC, it is up to the Provider to decide. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------090107050702080406030600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Mark,

That looks good to me.

Rob

On 16/01/15 22:51, Duckworth, Mark wrote:

Here is proposed framework text changes for a new MCC attribute.  Please comment.

 

Add to section 7:

 

7.2.1.4. Allow Subset Choice

 

The Allow Subset Choice MCC attribute is a boolean value, indicating whether or not the Provider allows the Consumer to choose a specific subset of the Captures referenced by the MCC.  If this attribute is true, and the MCC references other Captures, then the Consumer MAY select (in a Configure message) a specific subset of those Captures to be included in the MCC.  If this attribute is false, or the MCC does not reference other Captures, then the Consumer MUST NOT select a subset.

 

Change text in section 9:

 

- If the MCC attribute Allow Subset Choice is true, then the Consumer may or may not choose to receive all the indicated Captures.  It can choose to receive a sub-set of Captures indicated by the MCC.

 

For example if the Consumer receives:

        MCC1(VC1,VC2,VC3){attributes}

 

A Consumer could choose all the Captures within a MCCs however if the Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2).  If it wants all the individual Captures then it returns only the MCC identity (i.e. MCC1).  If the MCC in the advertisement does not reference any individual captures, or the Allow Subset Choice attribute is false, then the Consumer cannot choose what is included in the MCC, it is up to the Provider to decide.

 

Mark



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

--------------090107050702080406030600-- From nobody Mon Jan 19 22:44:54 2015 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 0DD7D1B2D66 for ; Mon, 19 Jan 2015 22:44:52 -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 32OirntDGrRB for ; Mon, 19 Jan 2015 22:44:50 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5401B2D68 for ; Mon, 19 Jan 2015 22:44:50 -0800 (PST) Received: from ppp118-209-239-62.lns20.mel8.internode.on.net ([118.209.239.62]:57179 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YDSX3-0000TZ-3V for clue@ietf.org; Tue, 20 Jan 2015 17:43:21 +1100 Message-ID: <54BDF95E.9050203@nteczone.com> Date: Tue, 20 Jan 2015 17:44:46 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] MCC attribute Allow Subset Choice 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, 20 Jan 2015 06:44:52 -0000 Hello Mark, Should we document what the behaviour is of the provider in response to the CONFIGURE when Allow subset choice is true? i.e. Allow Subset Choice is true and the consumer returns a sub-set then the provider MUST send that subset. A small nit on the text "A Consumer could choose all the Captures within a MCC however if the...". The can be deleted. Regards, Christian On 17/01/2015 9:51 AM, Duckworth, Mark wrote: > > Here is proposed framework text changes for a new MCC attribute. > Please comment. > > Add to section 7: > > 7.2.1.4. Allow Subset Choice > > The Allow Subset Choice MCC attribute is a boolean value, indicating > whether or not the Provider allows the Consumer to choose a specific > subset of the Captures referenced by the MCC. If this attribute is > true, and the MCC references other Captures, then the Consumer MAY > select (in a Configure message) a specific subset of those Captures to > be included in the MCC. If this attribute is false, or the MCC does > not reference other Captures, then the Consumer MUST NOT select a subset. > > Change text in section 9: > > - If the MCC attribute Allow Subset Choice is true, then the Consumer > may or may not choose to receive all the indicated Captures. It can > choose to receive a sub-set of Captures indicated by the MCC. > > For example if the Consumer receives: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within a MCCs however if the > Consumer determines that it doesn't want VC3 it can return > MCC1(VC1,VC2). If it wants all the individual Captures then it > returns only the MCC identity (i.e. MCC1). If the MCC in the > advertisement does not reference any individual captures, or the Allow > Subset Choice attribute is false, then the Consumer cannot choose what > is included in the MCC, it is up to the Provider to decide. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jan 20 06:34:00 2015 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 256901B2DAB for ; Tue, 20 Jan 2015 06:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS7RIT7bkWGd for ; Tue, 20 Jan 2015 06:33:56 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E7C1B2CCE for ; Tue, 20 Jan 2015 06:33:56 -0800 (PST) Received: from [216.82.249.212] by server-15.bemta-12.messagelabs.com id B6/6A-02699-4576EB45; Tue, 20 Jan 2015 14:33:56 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-219.messagelabs.com!1421764435!20840380!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8788 invoked from network); 20 Jan 2015 14:33:55 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 20 Jan 2015 14:33:55 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 20 Jan 2015 06:33:55 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 20 Jan 2015 06:33:53 -0800 Thread-Topic: [clue] MCC attribute Allow Subset Choice Thread-Index: AdA0fJr0/tx1V22dQTus8QRdHW2k2gAQWIfA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6FF4@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF6EB1@CRPMBOXPRD08.polycom.com> <54BDF95E.9050203@nteczone.com> In-Reply-To: <54BDF95E.9050203@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 Archived-At: Subject: Re: [clue] MCC attribute Allow Subset Choice 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, 20 Jan 2015 14:33:59 -0000 Hi Christian, Yes, I agree, I was thinking that when I wrote it, but forgot to put it in = the text! Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Tuesday, January 20, 2015 1:45 AM > To: clue@ietf.org > Subject: Re: [clue] MCC attribute Allow Subset Choice >=20 > Hello Mark, >=20 > Should we document what the behaviour is of the provider in response to > the CONFIGURE when Allow subset choice is true? i.e. Allow Subset Choice > is true and the consumer returns a sub-set then the provider MUST send > that subset. >=20 > A small nit on the text "A Consumer could choose all the Captures within > a MCC however if the...". The can be deleted. >=20 > Regards, Christian >=20 > On 17/01/2015 9:51 AM, Duckworth, Mark wrote: > > > > Here is proposed framework text changes for a new MCC attribute. > > Please comment. > > > > Add to section 7: > > > > 7.2.1.4. Allow Subset Choice > > > > The Allow Subset Choice MCC attribute is a boolean value, indicating > > whether or not the Provider allows the Consumer to choose a specific > > subset of the Captures referenced by the MCC. If this attribute is > > true, and the MCC references other Captures, then the Consumer MAY > > select (in a Configure message) a specific subset of those Captures to > > be included in the MCC. If this attribute is false, or the MCC does > > not reference other Captures, then the Consumer MUST NOT select a > subset. > > > > Change text in section 9: > > > > - If the MCC attribute Allow Subset Choice is true, then the Consumer > > may or may not choose to receive all the indicated Captures. It can > > choose to receive a sub-set of Captures indicated by the MCC. > > > > For example if the Consumer receives: > > > > MCC1(VC1,VC2,VC3){attributes} > > > > A Consumer could choose all the Captures within a MCCs however if the > > Consumer determines that it doesn't want VC3 it can return > > MCC1(VC1,VC2). If it wants all the individual Captures then it > > returns only the MCC identity (i.e. MCC1). If the MCC in the > > advertisement does not reference any individual captures, or the Allow > > Subset Choice attribute is false, then the Consumer cannot choose what > > is included in the MCC, it is up to the Provider to decide. > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jan 21 00:40:46 2015 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 5F6901A049A; Wed, 21 Jan 2015 00:40:39 -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 vRJqZbdiplpV; Wed, 21 Jan 2015 00:40:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 162D11A046D; Wed, 21 Jan 2015 00:40:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121084031.20751.96821.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 00:40:31 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-06.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: Wed, 21 Jan 2015 08:40:39 -0000 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 : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-06.txt Pages : 13 Date : 2015-01-21 Abstract: This document defines how to use the WebRTC Data Channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of two mechanisms for establishing a CLUE data channel: the Data Channel Establishment Protocol (DCEP) and the SDP-based "SCTP over DTLS" data channel negotiation mechanism. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 00:42:39 2015 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 AE9941A066C for ; Wed, 21 Jan 2015 00:42: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, 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 yndtQLgXlYCV for ; Wed, 21 Jan 2015 00:42:35 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379701A06E9 for ; Wed, 21 Jan 2015 00:42:35 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-fd-54bf6679ac22 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CD.82.04484.9766FB45; Wed, 21 Jan 2015 09:42:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Wed, 21 Jan 2015 09:42:33 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] Thread-Index: AdA1VjIfbxhopW+SS42fBZBUDROmTA== Date: Wed, 21 Jan 2015 08:42:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjW5l2v4Qg/79Ehb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtK3fSwFXwUrlhy6wtTAeI6vi5GTQ0LARGLJ+qfsELaYxIV7 69m6GLk4hASOMEqcP3aLCcJZzCjxcuJJxi5GDg42AQuJ7n/aIA0iAsoSRzf3s4HYwgJpEk3H W9kg4tkS97Z9YIKw9SR+fD/NAmKzCKhKTOl6B7aMV8BX4v6jX8wgNiPQ4u+n1oDVMwuIS9x6 Mp8J4iABiSV7zjND2KISLx//YwU5QUJASWLa1jSIch2JBbs/sUHY2hLLFr5mhhgvKHFy5hOW CYzCs5BMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECAzwg1t+G+xg fPnc8RCjAAejEg9vgd/+ECHWxLLiytxDjNIcLErivHkOG0KEBNITS1KzU1MLUovii0pzUosP MTJxcEo1MBYtKJlWvGX2Sr4VbCvbJBaYRa8LmR0a7BXOWb/kUQ3jow+ckXO2L2PY9F/vplXf vjWLskzZlEoWyKxcoiDpciLt1fbtilcz3eYu+524hmHBwQrxfTl3F7w90qHEmKrppRDn4l64 ed1GG01Vb9YFm3YktqYv2PVqus/HnuMlMofzuD1efxZYHaXEUpyRaKjFXFScCAA1FtZ9UQIA AA== Archived-At: Subject: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 21 Jan 2015 08:42:37 -0000 Hi, I have not submitted a new version (-06) of the data channel draft, which r= eflects the fact that the sctp-port attribute is (at least for now) mandato= ry. In addition, as the "DTLS/SCTP" protocol value has now been split into "UDP= /DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 12. tammikuuta 2015 15:50 To: Paul Kyzivat; clue@ietf.org Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 Hi, My understanding was that people did not want to define a default sctp-port= value. Personally I don't care - I just want to get the draft done. Anyway, that discussion belongs to MMUSIC. However, the CLUE documents stil= l need to be aligned with the latest MMUSIC draft. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 9. tammikuuta 2015 18:56 To: clue@ietf.org Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 On 1/8/15 6:31 PM, Christian Groves wrote: > Hello Christer, > > In draft-ietf-clue-datachannel-05 it says that the sctp-port is=20 > optional, i.e. > > 3.2.1.2. SDP sctp-port Attribute > > As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute > value is set to the SCTP port of the SCTPoDTLS association. > > NOTE: Usage of the SDP sctp-port attribute is optional. As defined > in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then > the default value is 5000. > > However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. That is a new change - one I was not in favor of. :-( > BTW clause > 4.5 in the draft should probably also be updated to add a=3Dsctp-port=20 > because it is mandatory. > > 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 nobody Wed Jan 21 09:45:35 2015 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 778511A1B4F; Wed, 21 Jan 2015 09:45:22 -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 zdA7ZAtko8M5; Wed, 21 Jan 2015 09:45:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E55701A1B3E; Wed, 21 Jan 2015 09:45:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121174519.21584.52761.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 09:45:19 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-20.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: Wed, 21 Jan 2015 17:45:23 -0000 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 : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-20.txt Pages : 82 Date : 2015-01-21 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 and SDP negotiation 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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 09:46:29 2015 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 540061A1B5D for ; Wed, 21 Jan 2015 09:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLNpIUTwRXPo for ; Wed, 21 Jan 2015 09:46:14 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.7]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519961A1B4F for ; Wed, 21 Jan 2015 09:46:14 -0800 (PST) Received: from [216.82.249.212] by server-7.bemta-12.messagelabs.com id 9F/00-03134-5E5EFB45; Wed, 21 Jan 2015 17:46:13 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-219.messagelabs.com!1421862373!21223824!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13268 invoked from network); 21 Jan 2015 17:46:13 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-9.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jan 2015 17:46:13 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 21 Jan 2015 09:46:12 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 21 Jan 2015 09:46:11 -0800 Thread-Topic: Framework version -20 available Thread-Index: AdA1m8zE3XK6Jj5eSoS9Mxq3oMuXtg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DCF71A2@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF71A2CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] Framework version -20 available 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, 21 Jan 2015 17:46:19 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF71A2CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, Stephan and I incorporated all the improvements from the WGLC feedback and = discussions. I don't know of any more open issues for the framework. Changes from 19 to 20: 1. Define term "CLUE" in introduction. 2. Add MCC attribute Allow Subset Choice. 3. Remove phrase about reducing SDP size, replace with potentially saving consumer resources. 4. Change example of a CLUE exchange that does not require SDP exchange. 5. Language attribute uses RFC5646. 6. Change Member person type to Attendee. Add Observer type. 7. Clarify DTLS/SRTP MUST be supported. 8. Change SHOULD NOT to MUST NOT regarding using xCard or description information for authorization decisions. 9. Clarify definition of Global View. 10. Refer to signaling doc regarding interoperating with a device that does not support CLUE. 11. Various minor editorial changes from working group last call feedback. 12. Capitalize defined terms. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF71A2CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,<= /o:p>

Stephan and I incorporated all the improvemen= ts from the WGLC feedback and discussions.  I don’t know of any = more open issues for the framework.

 

   Changes from 19 to 20:

 

     1. Define term "CLUE" in introduction.<= o:p>

     2. Add MCC attr= ibute Allow Subset Choice.

  &= nbsp;  3. Remove phrase about reducing SDP size, replace with

        poten= tially saving consumer resources.

 =     4. Change example of a CLUE exchange that does not requi= re SDP

     &nb= sp;  exchange.

   &n= bsp; 5. Language attribute uses RFC5646.

     6. Change Member person type to Attendee.  A= dd Observer type.

   &nbs= p; 7. Clarify DTLS/SRTP MUST be supported.

     8. Change SHOULD NOT to MUST NOT regarding usin= g xCard or

     = ;   description information for authorization decisions.

     9. Clarify definition o= f Global View.

     = 10. Refer to signaling doc regarding interoperating with a

        device that d= oes not support CLUE.

   =   11. Various minor editorial changes from working group last call

        = feedback.

     12. C= apitalize defined terms.

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DCF71A2CRPMBOXPRD08p_-- From nobody Wed Jan 21 20:17:54 2015 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 9AF851A026C for ; Wed, 21 Jan 2015 20:17:51 -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 lvQiu4WYtuF8 for ; Wed, 21 Jan 2015 20:17:49 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1711A01F4 for ; Wed, 21 Jan 2015 20:17:49 -0800 (PST) Received: from ppp118-209-122-23.lns20.mel4.internode.on.net ([118.209.122.23]:53484 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YE9DA-0006lz-Ht for clue@ietf.org; Thu, 22 Jan 2015 15:17:40 +1100 Message-ID: <54C079E7.1000202@nteczone.com> Date: Thu, 22 Jan 2015 15:17:43 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 22 Jan 2015 04:17:51 -0000 Hello Christer, The draft still contains both the ejzak and DCEP methods of establishing CLUE. We had a discussion in late November on the mailing list and it sounded like we were going to drop DCEP? Regards, Christian On 21/01/2015 7:42 PM, Christer Holmberg wrote: > Hi, > > I have not submitted a new version (-06) of the data channel draft, which reflects the fact that the sctp-port attribute is (at least for now) mandatory. > > In addition, as the "DTLS/SCTP" protocol value has now been split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 12. tammikuuta 2015 15:50 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 > > > Hi, > > My understanding was that people did not want to define a default sctp-port value. Personally I don't care - I just want to get the draft done. > > Anyway, that discussion belongs to MMUSIC. However, the CLUE documents still need to be aligned with the latest MMUSIC draft. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 9. tammikuuta 2015 18:56 > To: clue@ietf.org > Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 > > On 1/8/15 6:31 PM, Christian Groves wrote: >> Hello Christer, >> >> In draft-ietf-clue-datachannel-05 it says that the sctp-port is >> optional, i.e. >> >> 3.2.1.2. SDP sctp-port Attribute >> >> As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute >> value is set to the SCTP port of the SCTPoDTLS association. >> >> NOTE: Usage of the SDP sctp-port attribute is optional. As defined >> in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then >> the default value is 5000. >> >> However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. > That is a new change - one I was not in favor of. :-( > >> BTW clause >> 4.5 in the draft should probably also be updated to add a=sctp-port >> because it is mandatory. >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Jan 22 02:05:43 2015 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 1006F1A1DBC for ; Thu, 22 Jan 2015 02:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFQw0rbSz1FQ for ; Thu, 22 Jan 2015 02:05:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849381A19E9 for ; Thu, 22 Jan 2015 02:05:35 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-cd-54c0cb6d64aa Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 38.29.04231.D6BC0C45; Thu, 22 Jan 2015 11:05:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Thu, 22 Jan 2015 11:05:33 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] Thread-Index: AdA1VjIfbxhopW+SS42fBZBUDROmTAAm8ouAAA4sVNA= Date: Thu, 22 Jan 2015 10:05:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> In-Reply-To: <54C079E7.1000202@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7u6QMhBg+nKlt8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStj0atu9oIHEhW3fto1MLaJdDFyckgImEjc W3KbDcIWk7hwbz2QzcUhJHCEUaLt8nsWCGcxo8TFR7OYuhg5ONgELCS6/2mDNIgIhEt0bLvC CGILCxRKTP+xhRkiXiSx49hhKNtKYuLpeWALWARUJe43L2MFsXkFfCXWLZzHAjJSSCBfYuEm AZAwp4COxNbePhYQmxHonu+n1jCB2MwC4hK3nsxngrhTQGLJnvPMELaoxMvH/1ghbCWJtYe3 s0DU60gs2P2JDcLWlli28DUzxFpBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFu upGxXmpRZnJxcX6eXl5qySZGYIwc3PJbdwfj6teOhxgFOBiVeHg/zD8QIsSaWFZcmXuIUZqD RUmcN89hQ4iQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxsmTE00PsdR9rL8wx/CUY93Hi0pG Xf/fWM56G5NYtuJVX0jitq0yYlJ7ArbxZ2SJ+ubdb511qmHy3h2Buw9+z9wl31yTG1cy48D8 4qktEypSkp/37GCdeUtV0bArQ/vzuRUnmCXPNlRHVTllrGw+/0T5ysqlHaWCnDVhT96y/rsy cfal+/eqfyuxFGckGmoxFxUnAgD54+lScgIAAA== Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 22 Jan 2015 10:05:38 -0000 Hi, >The draft still contains both the ejzak and DCEP methods of establishing >= CLUE. We had a discussion in late November on the mailing list and it >soun= ded like we were going to drop DCEP? I guess I'll need to check the archives, but were we going to drop DCEP all= together, or were we going to say that it is not used if one is using the = SDP mechanism (Richard's draft)? Regards, Christer Regards, Christian On 21/01/2015 7:42 PM, Christer Holmberg wrote: > Hi, > > I have not submitted a new version (-06) of the data channel draft, which= reflects the fact that the sctp-port attribute is (at least for now) manda= tory. > > In addition, as the "DTLS/SCTP" protocol value has now been split into "U= DP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 12. tammikuuta 2015 15:50 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 > > > Hi, > > My understanding was that people did not want to define a default sctp-po= rt value. Personally I don't care - I just want to get the draft done. > > Anyway, that discussion belongs to MMUSIC. However, the CLUE documents st= ill need to be aligned with the latest MMUSIC draft. > > Regards, > > Christer > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 9. tammikuuta 2015 18:56 > To: clue@ietf.org > Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 > > On 1/8/15 6:31 PM, Christian Groves wrote: >> Hello Christer, >> >> In draft-ietf-clue-datachannel-05 it says that the sctp-port is=20 >> optional, i.e. >> >> 3.2.1.2. SDP sctp-port Attribute >> >> As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribu= te >> value is set to the SCTP port of the SCTPoDTLS association. >> >> NOTE: Usage of the SDP sctp-port attribute is optional. As defined >> in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then >> the default value is 5000. >> >> However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. > That is a new change - one I was not in favor of. :-( > >> BTW clause >> 4.5 in the draft should probably also be updated to add a=3Dsctp-port=20 >> because it is mandatory. >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jan 22 04:18:59 2015 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 63BC31A1A1D for ; Thu, 22 Jan 2015 04:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.47 X-Spam-Level: **** X-Spam-Status: No, score=4.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kfFBk5HMI00i for ; Thu, 22 Jan 2015 04:18:51 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1321ACC85 for ; Thu, 22 Jan 2015 04:18:50 -0800 (PST) X-ASG-Debug-ID: 1421929125-05f2751b144a7320001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id D3QdUf15WL4QvIWv (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jan 2015 13:18:45 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.1.106] ([151.77.73.196]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t0MCIdvR012946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 13:18:44 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_20A85075-FDD6-4EFF-AE71-595ABBEC6104" Date: Thu, 22 Jan 2015 13:18:36 +0100 X-ASG-Orig-Subj: Some thoughts on protocol and signalling drafts Message-Id: <7DF44B73-41FA-4283-BA0A-6B700C4F14B2@unina.it> To: CLUE Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1421929125 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.14527 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [clue] Some thoughts on protocol and signalling drafts 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, 22 Jan 2015 12:18:54 -0000 --Apple-Mail=_20A85075-FDD6-4EFF-AE71-595ABBEC6104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, while working on the updated version of the protocol draft, we ended up = doing a review of the signaling draft, which is, as you all know, = strictly coupled to our protocol document. Based on this, I would like to share with you a couple of = thoughts/doubts we still have on CLUE as a whole. Please bear with me if = I bring back to the fore issues we have already discussed in the past, = which are listed below. 1. CLUE and SIP Do we really need to state that SIP is mandatory for CLUE? I mean, our = feeling is that the current specification of CLUE actually gives for = granted that we use a mix of SDP and CLUE-level information in order to = properly setup (and modify) a CLUE-enabled session. Now, SDP can be sent = back and forth between two CLUE-enabled end-points in a number of = different ways, SIP being just one of them. Clearly enough, I am = thinking of the WebRTC scenario, whereby we might initially leverage a = signaling server in order to exchange SDPs between Producer and = Consumer. In that case, the very first SIP session setup (which is = needed in order to create the CLUE data channel) might be replaced by a = "signaling-server-mediated" WebRTC session negotiation. Once the session = is up and running, further SDP objects (used to negotiate = CLUE-controlled media) might be transferred directly across the CLUE = channel, in much the same way as it happens for CLUE protocol messages, = with no further need for a third-party mediator. I am not stating here that we have to bend towards this second approach; = though, I do think we might somehow relax the SIP requirement and allow = for more than a single alternative in CLUE. What=E2=80=99s your feeling = about this? 2. CLUE session recovery after a crash of the CLUE channel As per our discussions at the last IETF, the group seemed to agree on = the fact that in the event of a channel error during normal CLUE = operation, the media that were being CLUE-controlled do not have to be = torn down and can instead keep on going (even in the absence of CLUE = control). If we go to the CLUE participant=E2=80=99s state machine = (section 6 of the protocol draft) this means that we do not have to = release resources in this case, but simply move to the =E2=80=9CIdle=E2=80= =9D state and start the CLUE channel creation phase once again. In such = a situation, we would find ourselves in the need of: (i) re-establishing = the CLUE channel; (ii) adding the already available media (those which = were CLUE-controlled before channel crash) to the newly provided CLUE = channel. We were wondering if this can be achieved with the following sequence of = exchanges: a) I send a first SDP containing both the (non-CLUE-controlled) = available media and the m-line associated with the new CLUE channel I = want to setup. As an example, the excerpt below assumes one video stream = (with mid=3D2) is already available when I start re-negotiating the = CLUE channel (whose mid is 5). ... a=3Dgroup:CLUE 5 ... m=3Dvideo 6002 RTP/AVP 96 a=3Drtpmap:96 H264/90000 a=3Dfmtp:96 profile-level-id=3D42e016;max-mbps=3D108000;max-fs=3D3600 a=3Dsendrecv a=3Dmid:2 ... m=3Dapplication 6100 DTLS/SCTP webrtc-datachannel a=3Dfmtp:webrtc-datachannel max-message-size=3D100000 a=3Dsctp-port 5000 a=3Dmid:5 b) Once done with channel setup, I send a new SDP which simply adds the = video stream with mid=3D2 to the CLUE group, in order to indicate that = the stream in question is going to be CLUE-controlled once again: ... a=3Dgroup:CLUE 5 2 ... m=3Dvideo 6002 RTP/AVP 96 a=3Drtpmap:96 H264/90000 a=3Dfmtp:96 profile-level-id=3D42e016;max-mbps=3D108000;max-fs=3D3600 a=3Dsendrecv a=3Dmid:2 ... m=3Dapplication 6100 DTLS/SCTP webrtc-datachannel a=3Dfmtp:webrtc-datachannel max-message-size=3D100000 a=3Dsctp-port 5000 a=3Dmid:5 Thanks in advance for your comments and suggestions, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_20A85075-FDD6-4EFF-AE71-595ABBEC6104 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

while working on the updated version of the protocol draft, = we ended up doing a review of the signaling draft, which is, as you all = know, strictly coupled to our protocol document.
Based on this, I would like to share with you a couple of = thoughts/doubts we still have on CLUE as a whole. Please bear with me if = I bring back to the fore issues we have already discussed in the past, = which are listed below.

1. CLUE and SIP

Do we really need to state that SIP is mandatory for CLUE? I = mean, our feeling is that the current specification of CLUE actually = gives for granted that we use a mix of SDP and CLUE-level information in = order to properly setup (and modify) a CLUE-enabled session. Now, SDP = can be sent back and forth between two CLUE-enabled end-points in a = number of different ways, SIP being just one of them. Clearly enough, I = am thinking of the WebRTC scenario, whereby we might initially leverage = a signaling server in order to exchange SDPs between Producer and = Consumer. In that case, the very first SIP session setup (which is = needed in order to create the CLUE data channel) might be replaced by a = "signaling-server-mediated" WebRTC session negotiation. Once the session = is up and running, further SDP objects (used to negotiate = CLUE-controlled media) might be transferred directly across the CLUE = channel, in much the same way as it happens for CLUE protocol messages, = with no further need for a third-party mediator.
I = am not stating here that we have to bend towards this second approach; = though, I do think we might somehow relax the SIP requirement and allow = for more than a single alternative in CLUE. What=E2=80=99s your feeling = about this?

2. = CLUE session recovery after a crash of the CLUE channel

As per our discussions = at the last IETF, the group seemed to agree on the fact that in the = event of a channel error during normal CLUE operation, the media that = were being CLUE-controlled do not have to be torn down and can instead = keep on going (even in the absence of CLUE control). If we go to the = CLUE participant=E2=80=99s state machine (section 6 of the protocol = draft) this means that we do not have to release resources in this case, = but simply move to the =E2=80=9CIdle=E2=80=9D state and start the CLUE = channel creation phase once again. In such a situation, we would find = ourselves in the need of: (i) re-establishing the CLUE channel; (ii) = adding the already available media (those which were CLUE-controlled = before channel crash) to the newly provided CLUE channel.

We were wondering if = this can be achieved with the following sequence of exchanges:

a) I send a first SDP = containing both the (non-CLUE-controlled) available media and the m-line = associated with the new CLUE channel I want to setup. As an example, the = excerpt below assumes one video stream (with mid=3D2) is already = available when I start re-negotiating the  CLUE channel (whose mid = is 5).

...
a=3Dgroup:CLUE 5
...
m=3Dvideo 6002 RTP/AVP 96
a=3Drtpmap:96 H264/90000
a=3Dfmtp:96 = profile-level-id=3D42e016;max-mbps=3D108000;max-fs=3D3600
a=3Dsendrecv
a=3Dmid:2
...
m=3Dapplication 6100 DTLS/SCTP = webrtc-datachannel
a=3Dfmtp:webrtc-datachannel = max-message-size=3D100000
a=3Dsctp-port = 5000
a=3Dmid:5

b) Once done with channel setup, I send = a new SDP which simply adds the video stream with mid=3D2 to the CLUE = group, in order to indicate that the stream in question is going to be = CLUE-controlled once again:

...
a=3Dgroup:CLUE 5 = 2
...
m=3Dvideo 6002 RTP/AVP = 96
a=3Drtpmap:96 H264/90000
a=3Dfmtp:96 = profile-level-id=3D42e016;max-mbps=3D108000;max-fs=3D3600
a=3Dsendrecv
a=3Dmid:2
...
m=3Dapplication 6100 DTLS/SCTP = webrtc-datachannel
a=3Dfmtp:webrtc-datachannel = max-message-size=3D100000
a=3Dsctp-port = 5000
a=3Dmid:5

Thanks in advance for your comments and = suggestions,

Simon


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

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






= --Apple-Mail=_20A85075-FDD6-4EFF-AE71-595ABBEC6104-- From nobody Thu Jan 22 06:44:34 2015 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 7754D1ACCDF for ; Thu, 22 Jan 2015 06:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_dVP2hXWBWq for ; Thu, 22 Jan 2015 06:44:31 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 83E921AC82C for ; Thu, 22 Jan 2015 06:44:31 -0800 (PST) X-AuditID: 12074412-f79e46d0000036b4-05-54c10cce6ce9 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.42.14004.ECC01C45; Thu, 22 Jan 2015 09:44:30 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t0MEiU3Z016642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Jan 2015 09:44:30 -0500 Message-ID: <54C10CCE.20303@alum.mit.edu> Date: Thu, 22 Jan 2015 09:44:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixO6iqHuO52CIwc/1Fhb7T11mdmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bvBdNZCqbKVGydeo61gfGXWBcjJ4eEgInE/63TmCBsMYkL 99azgdhCApcZJa62unQxcgHZv5kkps5sYQVJ8ApoSqze8gXMZhFQlbjWMh2smU1AS2LOof8s ILaoQLLEmq2T2CHqBSVOznwCFOfgEAGyX14RBAkLCxRKHH29jg1i/npGidff+sHmcAr4SXzb 0M8MUs8sYC3xbXcRSJhZQF5i+9s5zBMY+WchmToLoWoWkqoFjMyrGOUSc0pzdXMTM3OKU5N1 i5MT8/JSi3TN9HIzS/RSU0o3MUJCT2gH4/qTcocYBTgYlXh4M4oPhAixJpYVV+YeYpTkYFIS 5f3/FyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhHcV18EQId6UxMqq1KJ8mJQ0B4uSOO/Pxep+ QgLpiSWp2ampBalFMFkZDg4lCd553ECNgkWp6akVaZk5JQhpJg5OkOFcUiLFqXkpqUWJpSUZ 8aBojC8GxiNIigdo70ywvcUFiblAUYjWU4yKUuK8i0HmCoAkMkrz4MbCEsorRnGgL4V5T4NU 8QCTEVz3K6DBTECDC7YfABlckoiQkmpg3LBog0ezxFp9lwrRja7qLKLcZ/dfZXkU8cCMUeqw yhFGt29e2x+cMYrsEXu3yMyzsEVrZeWXWQtuf11R4LLmzF2LSPVznBEhDz/K8Z/o9OieduRq wQ6jHpv+o/Z/73lmdXVH5vPeEDxeF1oR0Ta7052zf2X3od4qy6XcjqUFNe5mH5+/05+rxFKc kWioxVxUnAgAVRJgWgMDAAA= Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 22 Jan 2015 14:44:33 -0000 On 1/22/15 5:05 AM, Christer Holmberg wrote: > Hi, > >> The draft still contains both the ejzak and DCEP methods of establishing >CLUE. We had a discussion in late November on the mailing list and it >sounded like we were going to drop DCEP? > > I guess I'll need to check the archives, but were we going to drop DCEP all together, or were we going to say that it is not used if one is using the SDP mechanism (Richard's draft)? My recollection is that we agreed to drop DCEP, with the possibility to resurrect it if something goes wrong with the progression of the ejzak draft. Thanks, Paul > Regards, > > Christer > > > > Regards, Christian > > On 21/01/2015 7:42 PM, Christer Holmberg wrote: >> Hi, >> >> I have not submitted a new version (-06) of the data channel draft, which reflects the fact that the sctp-port attribute is (at least for now) mandatory. >> >> In addition, as the "DTLS/SCTP" protocol value has now been split into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 12. tammikuuta 2015 15:50 >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >> >> >> Hi, >> >> My understanding was that people did not want to define a default sctp-port value. Personally I don't care - I just want to get the draft done. >> >> Anyway, that discussion belongs to MMUSIC. However, the CLUE documents still need to be aligned with the latest MMUSIC draft. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 9. tammikuuta 2015 18:56 >> To: clue@ietf.org >> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >> >> On 1/8/15 6:31 PM, Christian Groves wrote: >>> Hello Christer, >>> >>> In draft-ietf-clue-datachannel-05 it says that the sctp-port is >>> optional, i.e. >>> >>> 3.2.1.2. SDP sctp-port Attribute >>> >>> As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute >>> value is set to the SCTP port of the SCTPoDTLS association. >>> >>> NOTE: Usage of the SDP sctp-port attribute is optional. As defined >>> in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present then >>> the default value is 5000. >>> >>> However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. >> That is a new change - one I was not in favor of. :-( >> >>> BTW clause >>> 4.5 in the draft should probably also be updated to add a=sctp-port >>> because it is mandatory. >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > 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 nobody Thu Jan 22 14:13:54 2015 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 44A1F1A87EF for ; Thu, 22 Jan 2015 14:13:53 -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 suVXLWYE_tSI for ; Thu, 22 Jan 2015 14:13:51 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECDDA1A87E3 for ; Thu, 22 Jan 2015 14:13:50 -0800 (PST) Received: from ppp118-209-138-236.lns20.mel8.internode.on.net ([118.209.138.236]:49928 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YEQ0K-0003eK-9d for clue@ietf.org; Fri, 23 Jan 2015 09:13:32 +1100 Message-ID: <54C17618.4080607@nteczone.com> Date: Fri, 23 Jan 2015 09:13:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> <54C10CCE.20303@alum.mit.edu> In-Reply-To: <54C10CCE.20303@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 22 Jan 2015 22:13:53 -0000 Hello Paul and Christer, On 23/01/2015 1:44 AM, Paul Kyzivat wrote: > On 1/22/15 5:05 AM, Christer Holmberg wrote: >> Hi, >> >>> The draft still contains both the ejzak and DCEP methods of >>> establishing >CLUE. We had a discussion in late November on the >>> mailing list and it >sounded like we were going to drop DCEP? >> >> I guess I'll need to check the archives, but were we going to drop >> DCEP all together, or were we going to say that it is not used if one >> is using the SDP mechanism (Richard's draft)? > > My recollection is that we agreed to drop DCEP, with the possibility > to resurrect it if something goes wrong with the progression of the > ejzak draft. > > Thanks, > Paul [CNG] Yes that was my recollection also. At least that's what I understood from the last IETF meeting minutes: https://tools.ietf.org/wg/clue/minutes?item=minutes-91-clue.html There would be one option and that the m= for that datachannel would be removed from the a=group:CLUE. The signalling document doesn't reflect that yet though. Regards, Christian > >> Regards, >> >> Christer >> >> >> >> Regards, Christian >> >> On 21/01/2015 7:42 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I have not submitted a new version (-06) of the data channel draft, >>> which reflects the fact that the sctp-port attribute is (at least >>> for now) mandatory. >>> >>> In addition, as the "DTLS/SCTP" protocol value has now been split >>> into "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: 12. tammikuuta 2015 15:50 >>> To: Paul Kyzivat; clue@ietf.org >>> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >>> >>> >>> Hi, >>> >>> My understanding was that people did not want to define a default >>> sctp-port value. Personally I don't care - I just want to get the >>> draft done. >>> >>> Anyway, that discussion belongs to MMUSIC. However, the CLUE >>> documents still need to be aligned with the latest MMUSIC draft. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 9. tammikuuta 2015 18:56 >>> To: clue@ietf.org >>> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >>> >>> On 1/8/15 6:31 PM, Christian Groves wrote: >>>> Hello Christer, >>>> >>>> In draft-ietf-clue-datachannel-05 it says that the sctp-port is >>>> optional, i.e. >>>> >>>> 3.2.1.2. SDP sctp-port Attribute >>>> >>>> As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port >>>> attribute >>>> value is set to the SCTP port of the SCTPoDTLS association. >>>> >>>> NOTE: Usage of the SDP sctp-port attribute is optional. As >>>> defined >>>> in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not >>>> present then >>>> the default value is 5000. >>>> >>>> However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. >>> That is a new change - one I was not in favor of. :-( >>> >>>> BTW clause >>>> 4.5 in the draft should probably also be updated to add a=sctp-port >>>> because it is mandatory. >>>> >>>> Regards, Christian >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> 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 nobody Thu Jan 22 14:33:25 2015 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 D7CEC1A8879 for ; Thu, 22 Jan 2015 14:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 3qzZgw7k5Do1 for ; Thu, 22 Jan 2015 14:33:22 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F77C1A8830 for ; Thu, 22 Jan 2015 14:33:22 -0800 (PST) Received: from ppp118-209-138-236.lns20.mel8.internode.on.net ([118.209.138.236]:50243 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YEQJD-0007n0-Tp for clue@ietf.org; Fri, 23 Jan 2015 09:33:04 +1100 Message-ID: <54C17AAC.2020908@nteczone.com> Date: Fri, 23 Jan 2015 09:33:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7DF44B73-41FA-4283-BA0A-6B700C4F14B2@unina.it> In-Reply-To: <7DF44B73-41FA-4283-BA0A-6B700C4F14B2@unina.it> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Some thoughts on protocol and signalling drafts 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, 22 Jan 2015 22:33:24 -0000 Hello Simon, Please see my replies below. Regards, Christian On 22/01/2015 11:18 PM, Simon Pietro Romano wrote: > Dear all, > > while working on the updated version of the protocol draft, we ended > up doing a review of the signaling draft, which is, as you all know, > strictly coupled to our protocol document. > Based on this, I would like to share with you a couple of > thoughts/doubts we still have on CLUE as a whole. Please bear with me > if I bring back to the fore issues we have already discussed in the > past, which are listed below. > > 1. CLUE and SIP > > Do we really need to state that SIP is mandatory for CLUE? I mean, our > feeling is that the current specification of CLUE actually gives for > granted that we use a mix of SDP and CLUE-level information in order > to properly setup (and modify) a CLUE-enabled session. Now, SDP can be > sent back and forth between two CLUE-enabled end-points in a number of > different ways, SIP being just one of them. Clearly enough, I am > thinking of the WebRTC scenario, whereby we might initially leverage a > signaling server in order to exchange SDPs between Producer and > Consumer. In that case, the very first SIP session setup (which is > needed in order to create the CLUE data channel) might be replaced by > a "signaling-server-mediated" WebRTC session negotiation. Once the > session is up and running, further SDP objects (used to negotiate > CLUE-controlled media) might be transferred directly across the CLUE > channel, in much the same way as it happens for CLUE protocol > messages, with no further need for a third-party mediator. > I am not stating here that we have to bend towards this second > approach; though, I do think we might somehow relax the SIP > requirement and allow for more than a single alternative in CLUE. > What’s your feeling about this? [CNG] I think the argument was that the IETF defines RFCs to support IETF protocols i.e. SIP. So if you use CLUE outside of IETF you can ignore the requirement. e.g. H.323 is being updated by in ITU-T SG16 Question 5 to also support CLUE. My opinion is that in the CLUE WG we should focus on SIP but if someone wants to also use CLUE with other protocols then that's good for CLUE. So I'm happy to relax the statement. > > 2. CLUE session recovery after a crash of the CLUE channel > > As per our discussions at the last IETF, the group seemed to agree on > the fact that in the event of a channel error during normal CLUE > operation, the media that were being CLUE-controlled do not have to be > torn down and can instead keep on going (even in the absence of CLUE > control). If we go to the CLUE participant’s state machine (section 6 > of the protocol draft) this means that we do not have to release > resources in this case, but simply move to the “Idle” state and start > the CLUE channel creation phase once again. In such a situation, we > would find ourselves in the need of: (i) re-establishing the CLUE > channel; (ii) adding the already available media (those which were > CLUE-controlled before channel crash) to the newly provided CLUE channel. [CNG] Wouldn't this depend on what layer the CLUE channel error occurs? e.g. if CLUE crashes then you simply resend OPTIONs etc. on the existing SCTP stream. If the SCTP stream crashes you'd try a reset and try to establishment, etc? Do we need an updated SDP O/A? Also given that CLUE would only be one of several possible WebRTC data channels what behaviour do these have? > > We were wondering if this can be achieved with the following sequence > of exchanges: > > a) I send a first SDP containing both the (non-CLUE-controlled) > available media and the m-line associated with the new CLUE channel I > want to setup. As an example, the excerpt below assumes one video > stream (with mid=2) is already available when I start re-negotiating > the CLUE channel (whose mid is 5). > > ... > a=group:CLUE 5 > ... > m=video 6002 RTP/AVP 96 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 > a=sendrecv > a=mid:2 > ... > m=application 6100 DTLS/SCTP webrtc-datachannel > a=fmtp:webrtc-datachannel max-message-size=100000 > a=sctp-port 5000 > a=mid:5 > > b) Once done with channel setup, I send a new SDP which simply adds > the video stream with mid=2 to the CLUE group, in order to indicate > that the stream in question is going to be CLUE-controlled once again: > > ... > a=group:CLUE 5 2 > ... > m=video 6002 RTP/AVP 96 > a=rtpmap:96 H264/90000 > a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 > a=sendrecv > a=mid:2 > ... > m=application 6100 DTLS/SCTP webrtc-datachannel > a=fmtp:webrtc-datachannel max-message-size=100000 > a=sctp-port 5000 > a=mid:5 > > Thanks in advance for your comments and suggestions, > > Simon > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jan 23 01:07:44 2015 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 7250E1A1A91 for ; Fri, 23 Jan 2015 01:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uUoRDQFbq7tn for ; Fri, 23 Jan 2015 01:07:38 -0800 (PST) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1011A040C for ; Fri, 23 Jan 2015 01:07:37 -0800 (PST) X-ASG-Debug-ID: 1422004055-05ce377321fe95b0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id GbiwFTgAyDHuQUD8 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 10:07:35 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id t0N97YGn024497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 10:07:35 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_12978B8C-376F-466C-947F-A3F3CB07AE37" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Some thoughts on protocol and signalling drafts In-Reply-To: <54C17AAC.2020908@nteczone.com> Date: Fri, 23 Jan 2015 10:07:34 +0100 Message-Id: <25E37DC0-20C0-49B6-B516-EF7BB0A880CD@unina.it> References: <7DF44B73-41FA-4283-BA0A-6B700C4F14B2@unina.it> <54C17AAC.2020908@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1422004055 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0005 1.0000 -2.0178 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.14555 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: clue@ietf.org Subject: Re: [clue] Some thoughts on protocol and signalling drafts 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, 23 Jan 2015 09:07:40 -0000 --Apple-Mail=_12978B8C-376F-466C-947F-A3F3CB07AE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Christian, my further comments in-line. >> 1. CLUE and SIP >>=20 >> Do we really need to state that SIP is mandatory for CLUE? I mean, = our feeling is that the current specification of CLUE actually gives for = granted that we use a mix of SDP and CLUE-level information in order to = properly setup (and modify) a CLUE-enabled session. Now, SDP can be sent = back and forth between two CLUE-enabled end-points in a number of = different ways, SIP being just one of them. Clearly enough, I am = thinking of the WebRTC scenario, whereby we might initially leverage a = signaling server in order to exchange SDPs between Producer and = Consumer. In that case, the very first SIP session setup (which is = needed in order to create the CLUE data channel) might be replaced by a = "signaling-server-mediated" WebRTC session negotiation. Once the session = is up and running, further SDP objects (used to negotiate = CLUE-controlled media) might be transferred directly across the CLUE = channel, in much the same way as it happens for CLUE protocol messages, = with no further need for a third-party mediator. >> I am not stating here that we have to bend towards this second = approach; though, I do think we might somehow relax the SIP requirement = and allow for more than a single alternative in CLUE. What=92s your = feeling about this? >=20 > [CNG] I think the argument was that the IETF defines RFCs to support = IETF protocols i.e. SIP. So if you use CLUE outside of IETF you can = ignore the requirement. e.g. H.323 is being updated by in ITU-T SG16 = Question 5 to also support CLUE. My opinion is that in the CLUE WG we = should focus on SIP but if someone wants to also use CLUE with other = protocols then that's good for CLUE. So I'm happy to relax the = statement. [SPR] The example I was making (CLUE with RtcWeb/WebRTC) is 100% INSIDE = the IETF, isn=92t it? >=20 >> 2. CLUE session recovery after a crash of the CLUE channel >>=20 >> As per our discussions at the last IETF, the group seemed to agree on = the fact that in the event of a channel error during normal CLUE = operation, the media that were being CLUE-controlled do not have to be = torn down and can instead keep on going (even in the absence of CLUE = control). If we go to the CLUE participant=92s state machine (section 6 = of the protocol draft) this means that we do not have to release = resources in this case, but simply move to the =93Idle=94 state and = start the CLUE channel creation phase once again. In such a situation, = we would find ourselves in the need of: (i) re-establishing the CLUE = channel; (ii) adding the already available media (those which were = CLUE-controlled before channel crash) to the newly provided CLUE = channel. >=20 > [CNG] Wouldn't this depend on what layer the CLUE channel error = occurs? e.g. if CLUE crashes then you simply resend OPTIONs etc. on the = existing SCTP stream. If the SCTP stream crashes you'd try a reset and = try to establishment, etc? Do we need an updated SDP O/A? [SPR] As I was trying to explain in the SDP excerpts, I think the new = O/A is needed in order to: (i) setup a new CLUE data channel; (ii) put = the (non-clue-controlled) existing media under CLUE control. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_12978B8C-376F-466C-947F-A3F3CB07AE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Christian,

my further comments in-line.

1. CLUE and SIP

Do we = really need to state that SIP is mandatory for CLUE? I mean, our feeling = is that the current specification of CLUE actually gives for granted = that we use a mix of SDP and CLUE-level information in order to properly = setup (and modify) a CLUE-enabled session. Now, SDP can be sent back and = forth between two CLUE-enabled end-points in a number of different ways, = SIP being just one of them. Clearly enough, I am thinking of the WebRTC = scenario, whereby we might initially leverage a signaling server in = order to exchange SDPs between Producer and Consumer. In that case, the = very first SIP session setup (which is needed in order to create the = CLUE data channel) might be replaced by a "signaling-server-mediated" = WebRTC session negotiation. Once the session is up and running, further = SDP objects (used to negotiate CLUE-controlled media) might be = transferred directly across the CLUE channel, in much the same way as it = happens for CLUE protocol messages, with no further need for a = third-party mediator.
I am not stating here that we have = to bend towards this second approach; though, I do think we might = somehow relax the SIP requirement and allow for more than a single = alternative in CLUE. What=92s your feeling about this?

[CNG] I think the argument = was that the IETF defines RFCs to support IETF protocols i.e. SIP. So if = you use CLUE outside of IETF you can ignore the requirement. e.g. H.323 = is being updated by in ITU-T SG16 Question 5 to also support CLUE. My = opinion is that in the CLUE WG we should focus on SIP but if someone = wants to also use CLUE with other protocols then that's good for CLUE. = So I'm happy to relax the statement.

[SPR] The example I was making (CLUE with = RtcWeb/WebRTC) is 100% INSIDE the IETF, isn=92t it?


2. CLUE session = recovery after a crash of the CLUE channel

As= per our discussions at the last IETF, the group seemed to agree on the = fact that in the event of a channel error during normal CLUE operation, = the media that were being CLUE-controlled do not have to be torn down = and can instead keep on going (even in the absence of CLUE control). If = we go to the CLUE participant=92s state machine (section 6 of the = protocol draft) this means that we do not have to release resources in = this case, but simply move to the =93Idle=94 state and start the CLUE = channel creation phase once again. In such a situation, we would find = ourselves in the need of: (i) re-establishing the CLUE channel; (ii) = adding the already available media (those which were CLUE-controlled = before channel crash) to the newly provided CLUE channel.

[CNG] Wouldn't this depend = on what layer the CLUE channel error occurs? e.g. if CLUE crashes then = you simply resend OPTIONs etc. on the existing SCTP stream. If the SCTP = stream crashes you'd try a reset and try to establishment, etc? Do we = need an updated SDP O/A?

[SPR] As I was trying to explain in the SDP = excerpts, I think the new O/A is needed in order to: (i) setup a new = CLUE data channel; (ii) put the (non-clue-controlled) existing media = under CLUE control.

Cheers,

Simon


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

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






= --Apple-Mail=_12978B8C-376F-466C-947F-A3F3CB07AE37-- From nobody Fri Jan 23 01:20:45 2015 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 49ACF1A028A for ; Fri, 23 Jan 2015 01:20:39 -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 7-5ixi7PggBQ for ; Fri, 23 Jan 2015 01:20:36 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01E31A026C for ; Fri, 23 Jan 2015 01:20:35 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id x3so6409548wes.5 for ; Fri, 23 Jan 2015 01:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=ulsNDLqFMXKy0Zs1I31TKMtIi68Ks6ok3I5MCHP3SbA=; b=tUChV9Om20idoGMzT4rcCetC8KLayEw/lOGW4ocf7CnskteDnB6YOU8q/x6BOnHhKO GgsdLwgT8+gJNKoO+tE0Wpb/b3axwxuZmtrF4nfFKjB+t3z05JH7LyCZAXLhgCTRs8LB u+C3S5yIyrb4mnHEPGMnBNgaN4EhRqcUZJL5Y/Zr1iXHWOz7G5sBQvLV5NupER3bZAIb uyDkdgoDCEiXD10O4aso+FzOpzOdpHYuhqi9T8jGIKwNdpfg4NyKK6d2fEDTqdhUe9aq cv2jEpUtdicRYnSj7hJtPkaup718apd4Pu6VzP6qpiExckExHTgcGNd/WhRtNpuzcgMu +wgQ== X-Received: by 10.194.24.195 with SMTP id w3mr11221513wjf.135.1422004834385; Fri, 23 Jan 2015 01:20:34 -0800 (PST) Received: from RoniE ([109.66.36.7]) by mx.google.com with ESMTPSA id dp8sm987819wib.20.2015.01.23.01.20.32 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Jan 2015 01:20:33 -0800 (PST) From: "Roni Even" To: Date: Fri, 23 Jan 2015 11:20:27 +0200 Message-ID: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D7_01D036FE.988B3F40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA27XjoGY4cm7oLQbmd7tobFaVqcg== Content-Language: en-us Archived-At: Subject: [clue] short WGLC on draft-ietf-clue-framework-20 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, 23 Jan 2015 09:20:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D7_01D036FE.988B3F40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There were good reviews during the WGLC on the framework document. Mark updated the document to include all the issues that were discussed in http://tools.ietf.org/html/draft-ietf-clue-framework-20 In order to verify that all concerns were addressed we will have a short WGLC till February 4th and in there are no more open issues we will send the document to publication. Mark noted the following changes from 19 to 20: 1. Define term "CLUE" in introduction. 2. Add MCC attribute Allow Subset Choice. 3. Remove phrase about reducing SDP size, replace with potentially saving consumer resources. 4. Change example of a CLUE exchange that does not require SDP exchange. 5. Language attribute uses RFC5646. 6. Change Member person type to Attendee. Add Observer type. 7. Clarify DTLS/SRTP MUST be supported. 8. Change SHOULD NOT to MUST NOT regarding using xCard or description information for authorization decisions. 9. Clarify definition of Global View. 10. Refer to signaling doc regarding interoperating with a device that does not support CLUE. 11. Various minor editorial changes from working group last call feedback. 12. Capitalize defined terms. Thanks Roni Even CLUE co-chair ------=_NextPart_000_01D7_01D036FE.988B3F40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There were good = reviews during the WGLC on the framework document.

 

Mark updated = the document to include all the issues that were discussed in http://t= ools.ietf.org/html/draft-ietf-clue-framework-20

 

In order to = verify that all concerns were addressed we will have a short WGLC till = February 4th and in there are no more open issues we = will send the document to publication.

 

 

 

Mark noted = the following changes from 19 to 20:

 

     1. Define term = "CLUE" in introduction.

     2. Add MCC attribute Allow = Subset Choice.

     3. Remove phrase about = reducing SDP size, replace with

        potentially = saving consumer resources.

     4. Change example of a CLUE = exchange that does not require SDP

        = exchange.

     5. = Language attribute uses RFC5646.

     6. Change Member person type = to Attendee.  Add Observer type.

     7. Clarify DTLS/SRTP MUST be = supported.

     = 8. Change SHOULD NOT to MUST NOT regarding using xCard = or

        description = information for authorization decisions.

     9. Clarify definition of = Global View.

     = 10. Refer to signaling doc regarding interoperating with = a

        device that = does not support CLUE.

     11. Various minor editorial = changes from working group last call

        = feedback.

     = 12. Capitalize defined terms.

 

Thanks

Roni = Even

CLUE = co-chair

------=_NextPart_000_01D7_01D036FE.988B3F40-- From nobody Fri Jan 23 05:33:32 2015 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 B149B1A90B8 for ; Fri, 23 Jan 2015 05:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCB8HKQ1IcCd for ; Fri, 23 Jan 2015 05:33:28 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6135F1A90B6 for ; Fri, 23 Jan 2015 05:33:28 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-70-54c24da629b0 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.49.04076.6AD42C45; Fri, 23 Jan 2015 14:33:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 14:33:25 +0100 From: Christer Holmberg To: Simon Pietro Romano , Christian Groves Thread-Topic: [clue] Some thoughts on protocol and signalling drafts Thread-Index: AQHQNj2c7bdGm4WA5kKvHC2czZQgFZzMqZUAgACxOACAAFc3MA== Date: Fri, 23 Jan 2015 13:33:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D67A06C@ESESSMB209.ericsson.se> References: <7DF44B73-41FA-4283-BA0A-6B700C4F14B2@unina.it> <54C17AAC.2020908@nteczone.com> <25E37DC0-20C0-49B6-B516-EF7BB0A880CD@unina.it> In-Reply-To: <25E37DC0-20C0-49B6-B516-EF7BB0A880CD@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje4y30MhBtMvSll8ed/IYrH/1GVm i21tN5gdmD2WLPnJ5LHi/EwWjx9bnjIFMEdx2aSk5mSWpRbp2yVwZczpe8BW8EmuouP6FKYG xiMSXYycHBICJhKT3x5hhbDFJC7cW8/WxcjFISRwhFHiy9HvjBDOYkaJD19+AjkcHGwCFhLd /7RBGkQE4iVW7H3ODGIzCyhLfG3YxARSIizgLLHwdyaIKSLgIvFsUxBEtZPEq/sPWEBsFgFV ia5JfxlBbF4BX4mfG6czQWzqZ5RondHLBpLgFLCR+LduLlgDI9Bt30+tYYJYJS5x68l8Joib BSSW7DnPDGGLSrx8/A/qFyWJHxsusUDU60gs2P2JDcLWlli28DUzxGJBiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYEQd3PLbagfjweeOhxgF OBiVeHgLPh4MEWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD Y7zxbr6AqJjeDQ0XOb/NrlSarT0nOjrZPyWVQTznul74dOG9Tf/iL86vWHrsQHrdg2zriuZW R7meM6+mlLkdT5m/YlEY5yWHHV/EN7QoCEsbGU5wWsI304PfZIniEr8vrjKy6Q+ttef4mj84 19qy9XNbTLWL3nuFe2o/br8u2HHRUmXDY5nDSizFGYmGWsxFxYkAR24WQYkCAAA= Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Some thoughts on protocol and signalling drafts 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, 23 Jan 2015 13:33:30 -0000 Hi, > my further comments in-line. > > 1. CLUE and SIP > > Do we really need to state that SIP is mandatory for CLUE? I mean, our fe= eling is that the current specification of CLUE actually gives for granted = that we use a mix of SDP and CLUE-level information in order to properly se= tup (and modify) a CLUE-enabled > session. Now, SDP can be sent back and fo= rth between two CLUE-enabled end-points in a number of different ways, SIP = being just one of them. Clearly enough, I am thinking of the WebRTC scenari= o, whereby we might initially leverage a signaling server in > order to exc= hange SDPs between Producer and Consumer. In that case, the very first SIP = session setup (which is needed in order to create the CLUE data channel) mi= ght be replaced by a "signaling-server-mediated" WebRTC session negotiation= . Once the=20 > session is up and running, further SDP objects (used to negotiate CLUE-co= ntrolled media) might be transferred directly across the CLUE channel, in m= uch the same way as it happens for CLUE protocol messages, with no further = need for a third-party=20 > mediator. > I am not stating here that we have to bend towards this second approach; = though, I do think we might somehow relax the SIP requirement and allow for= more than a single alternative in CLUE. What's your feeling about this? > > [CNG] I think the argument was that the IETF defines RFCs to support IETF= protocols i.e. SIP. So if you use CLUE outside of IETF you can ignore the = requirement. e.g. H.323 is being updated by in ITU-T SG16 Question 5 to als= o support CLUE. My opinion is=20 > that in the CLUE WG we should focus on SIP but if someone wants to also u= se CLUE with other protocols then that's good for CLUE. So I'm happy to rel= ax the statement. > > [SPR] The example I was making (CLUE with RtcWeb/WebRTC) is 100% INSIDE t= he IETF, isn't it? In my opinion, the purpose and scope of the CLUE *WG* is to define how the = CLUE *protocol* is used with SIP/SDP. I see no reason to forbid others from defining usage of the CLUE *protocol*= in other environments. ------------- > 2. CLUE session recovery after a crash of the CLUE channel > > As per our discussions at the last IETF, the group seemed to agree on the= fact that in the event of a channel error during normal CLUE operation, th= e media that were being CLUE-controlled do not have to be torn down and can= instead keep on going (even > in the absence of CLUE control). If we go to= the CLUE participant's state machine (section 6 of the protocol draft) thi= s means that we do not have to release resources in this case, but simply m= ove to the "Idle" state and start the CLUE channel creation=20 > phase once again. In such a situation, we would find ourselves in the nee= d of: (i) re-establishing the CLUE channel; (ii) adding the already availab= le media (those which were CLUE-controlled before channel crash) to the new= ly provided CLUE channel. > > [CNG] Wouldn't this depend on what layer the CLUE channel error occurs? e= .g. if CLUE crashes then you simply resend OPTIONs etc. on the existing SCT= P stream. If the SCTP stream crashes you'd try a reset and try to establish= ment, etc? Do we need an=20 > updated SDP O/A?=20 > > [SPR] As I was trying to explain in the SDP excerpts, I think the new O/A= is needed in order to: (i) setup a new CLUE data channel; (ii) put the (no= n-clue-controlled) existing media under CLUE control. I am not sure I understand (ii). How is putting non-clue-controlled media u= nder CLUE control related to a crash of the CLUE channel? I don't think you need a new SDP O/A in order to re-establish the data chan= nel, unless some associated parameters have changed, or if you realize that= it doesn't work (perhaps some gates that were opened for the data channel = have been closed due to the failure). Regards, Christer From nobody Fri Jan 23 06:56:15 2015 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 193D41A9062 for ; Fri, 23 Jan 2015 06:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7qByyB7vz0P for ; Fri, 23 Jan 2015 06:56:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 504F41A017D for ; Fri, 23 Jan 2015 06:56:10 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-aa-54c26108ba0d Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7D.17.04076.80162C45; Fri, 23 Jan 2015 15:56:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 15:56:07 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] Thread-Index: AdA1VjIfbxhopW+SS42fBZBUDROmTAAm8ouAAA4sVNAAB7eNAAA0wh6g Date: Fri, 23 Jan 2015 14:56:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D67B6CA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> <54C10CCE.20303@alum.mit.edu> In-Reply-To: <54C10CCE.20303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjS5H4qEQg11dyhb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJUxcap/wSPZimNrP7A1MC6W6GLk4JAQMJH4 MSWyi5ETyBSTuHBvPRuILSRwhFHiwHHTLkYuIHsxo8SVX8+ZQOrZBCwkuv9pg9SICHhK7Pg4 hRnEFhYolJj+YwszRLxIYsexw1C2m8S/WVvBZrIIqErMbtjNDmLzCvhKzNy1mgli/mVGiU2b 2xhBEpwCWhKbFywAa2YEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtJ4seG SywQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFKFqcWlyc m25kpJdalJlcXJyfp5eXWrKJERgjB7f8ttrBePC54yFGAQ5GJR7ego8HQ4RYE8uKK3MPMUpz sCiJ89oZHwoREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKjSY/Z5+pNViXfva/3WSNf35Xm5 me117nqmDwVNG3b1CT3XETadpq33u7Va9+hUVZGSMz9XLJO7I+I+qTq7XlNzypG3PT6xXy+Y LFjasjr6j9j+WWuuVmQX8r06Mu+2j8Lfpbf7d39/evTnw40PfE/G13ULrv0+xbcuPuv+v97G 1Y6ugZJJtblKLMUZiYZazEXFiQAbd5lIcgIAAA== Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 23 Jan 2015 14:56:13 -0000 Hi, >>> The draft still contains both the ejzak and DCEP methods of establishin= g >CLUE. We had a discussion in late November on the mailing list and it >s= ounded like we were going to drop DCEP? >> >> I guess I'll need to check the archives, but were we going to drop DCEP = all together, or were we going to say that it is not used if one is using t= he SDP mechanism (Richard's draft)? > > My recollection is that we agreed to drop DCEP, with the possibility to r= esurrect it if something goes wrong with the progression of the ejzak draft= . Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE wou= ld at least require the usage of SDP, right? Regards, Christer > On 21/01/2015 7:42 PM, Christer Holmberg wrote: >> Hi, >> >> I have not submitted a new version (-06) of the data channel draft, whic= h reflects the fact that the sctp-port attribute is (at least for now) mand= atory. >> >> In addition, as the "DTLS/SCTP" protocol value has now been split into "= UDP/DTLS/SCTP" and "TCP/DTLS/SCTP", I tried to reflect that. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 12. tammikuuta 2015 15:50 >> To: Paul Kyzivat; clue@ietf.org >> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >> >> >> Hi, >> >> My understanding was that people did not want to define a default sctp-p= ort value. Personally I don't care - I just want to get the draft done. >> >> Anyway, that discussion belongs to MMUSIC. However, the CLUE documents s= till need to be aligned with the latest MMUSIC draft. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 9. tammikuuta 2015 18:56 >> To: clue@ietf.org >> Subject: Re: [clue] SCTP port in draft-ietf-clue-datachannel-05 >> >> On 1/8/15 6:31 PM, Christian Groves wrote: >>> Hello Christer, >>> >>> In draft-ietf-clue-datachannel-05 it says that the sctp-port is=20 >>> optional, i.e. >>> >>> 3.2.1.2. SDP sctp-port Attribute >>> >>> As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attri= bute >>> value is set to the SCTP port of the SCTPoDTLS association. >>> >>> NOTE: Usage of the SDP sctp-port attribute is optional. As defin= ed >>> in [I-D.ietf-mmusic-sctp-sdp], if the attribute is not present th= en >>> the default value is 5000. >>> >>> However draft-ietf-mmusic-sctp-sdp-11 says it is mandatory. >> That is a new change - one I was not in favor of. :-( >> >>> BTW clause >>> 4.5 in the draft should probably also be updated to add a=3Dsctp-port=20 >>> because it is mandatory. >>> >>> Regards, Christian >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > 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 nobody Sun Jan 25 20:53:54 2015 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 2BD061A1BE0 for ; Sun, 25 Jan 2015 20:53:51 -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_20=-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 4CBvkmfsZLi2 for ; Sun, 25 Jan 2015 20:53:49 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41AEF1A1BC9 for ; Sun, 25 Jan 2015 20:53:49 -0800 (PST) Received: from ppp118-209-175-48.lns20.mel8.internode.on.net ([118.209.175.48]:52316 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YFbfl-00077u-B1 for clue@ietf.org; Mon, 26 Jan 2015 15:53:13 +1100 Message-ID: <54C5C858.1040106@nteczone.com> Date: Mon, 26 Jan 2015 15:53:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> <54C10CCE.20303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D67B6CA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D67B6CA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 26 Jan 2015 04:53:51 -0000 Hello Christer, On 24/01/2015 1:56 AM, Christer Holmberg wrote: > Hi, > >>>> The draft still contains both the ejzak and DCEP methods of establishing >CLUE. We had a discussion in late November on the mailing list and it >sounded like we were going to drop DCEP? >>> I guess I'll need to check the archives, but were we going to drop DCEP all together, or were we going to say that it is not used if one is using the SDP mechanism (Richard's draft)? >> My recollection is that we agreed to drop DCEP, with the possibility to resurrect it if something goes wrong with the progression of the ejzak draft. > Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE would at least require the usage of SDP, right? [CNG] For our work yes, however I don' think SDP is mandatory in all cases. So long as whatever ever is used to describe the encodings/bearer (e.g. H.245) contains a reference to the CLUE encodingID then I think CLUE can be used. Regards, Christian From nobody Mon Jan 26 00:25:12 2015 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 7163E1A8748 for ; Mon, 26 Jan 2015 00:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4j1F0CO5RwU for ; Mon, 26 Jan 2015 00:25:09 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37451A8739 for ; Mon, 26 Jan 2015 00:25:08 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-2c-54c5f9e1ab71 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 72.A2.04076.1E9F5C45; Mon, 26 Jan 2015 09:25:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 09:25:05 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] Thread-Index: AdA1VjIfbxhopW+SS42fBZBUDROmTAAm8ouAAA4sVNAAB7eNAAA0wh6gAH/GbgAACXKFMA== Date: Mon, 26 Jan 2015 08:25:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D67D417@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> <54C10CCE.20303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D67B6CA@ESESSMB209.ericsson.se> <54C5C858.1040106@nteczone.com> In-Reply-To: <54C5C858.1040106@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje7Dn0dDDB59NrP48r6RxWL/qcvM DkweS5b8ZPJYcX4mSwBTFJdNSmpOZllqkb5dAldG/5kP7AXLOCqePG9nbGDcz9bFyMEhIWAi sWxFWRcjJ5ApJnHh3nqgMBeHkMARRomdB5ezQziLGSXeXHnHDNLAJmAh0f1PG6RBRCBcomPb FUYQW1igUGL6jy3MEPEiiR3HDoOViwiESTRuZQExWQRUJaY3iIFU8Ar4SrRd+QfWKSSwk0li 3ZkqkBJOAR2JiVfLQcKMQNd8P7WGCcRmFhCXuPVkPhPElQISS/acZ4awRSVePv7HCvGIksS0 rWkQ5ToSC3Z/YoOwtSWWLXzNDLFVUOLkzCcsExhFZyGZOgtJyywkLbOQtCxgZFnFKFqcWlyc m25kpJdalJlcXJyfp5eXWrKJERgdB7f8ttrBePC54yFGAQ5GJR7eDWuPhgixJpYVV+YeYpTm YFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFGnidZt+Xh/s/nZY1f3z0cuo/l tgPz+67UOI/r/HkFx6rX763kruAyS8/g8FdJYy32eLtZhFfuAsOy+Iq41+us2A8H7FSMeRfv 885iim6bkXJnhYzp6dm/e8LaEsSvbV/8RVXo9xexjUy1K5N+TYq0SbBxuyLxJ7b8yeuJW39q sFjEbhcqUmIpzkg01GIuKk4EAI4u1VpvAgAA Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 26 Jan 2015 08:25:10 -0000 Hi, >>>>> The draft still contains both the ejzak and DCEP methods of establish= ing >CLUE. We had a discussion in late November on the mailing list and it = >sounded like we were going to drop DCEP? >>>> I guess I'll need to check the archives, but were we going to drop DCE= P all together, or were we going to say that it is not used if one is using= the SDP mechanism (Richard's draft)? >>> My recollection is that we agreed to drop DCEP, with the possibility to= resurrect it if something goes wrong with the progression of the ejzak dra= ft. >> Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE = would at least require the usage of SDP, right? >[CNG] For our work yes, however I don' think SDP is mandatory in all cases= . So long as whatever ever is used to describe the encodings/bearer (e.g. H= .245) contains a reference to the CLUE encodingID then I think CLUE can be = used. Sure.=20 But, then, if you want to use DCEP for H.245, you would have to define that= separately. Regards, Christer From nobody Mon Jan 26 02:16:51 2015 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 8083C1A8897 for ; Mon, 26 Jan 2015 02:16: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 85NTNeXzJS4n for ; Mon, 26 Jan 2015 02:16:48 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86C21A8874 for ; Mon, 26 Jan 2015 02:16:47 -0800 (PST) Received: from ppp118-209-245-89.lns20.mel8.internode.on.net ([118.209.245.89]:54514 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YFgiH-0008Mj-HX; Mon, 26 Jan 2015 21:16:09 +1100 Message-ID: <54C6140B.9010108@nteczone.com> Date: Mon, 26 Jan 2015 21:16:43 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D671FFC@ESESSMB209.ericsson.se> <54C079E7.1000202@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D675A49@ESESSMB209.ericsson.se> <54C10CCE.20303@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D67B6CA@ESESSMB209.ericsson.se> <54C5C858.1040106@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D67D417@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D67D417@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; 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: Archived-At: Subject: Re: [clue] Draft new version: CLUE data channel -06 [was: SCTP port in draft-ietf-clue-datachannel-05] 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, 26 Jan 2015 10:16:49 -0000 Hello Christer, On 26/01/2015 7:25 PM, Christer Holmberg wrote: > Hi, > >>>>>> The draft still contains both the ejzak and DCEP methods of establishing >CLUE. We had a discussion in late November on the mailing list and it >sounded like we were going to drop DCEP? >>>>> I guess I'll need to check the archives, but were we going to drop DCEP all together, or were we going to say that it is not used if one is using the SDP mechanism (Richard's draft)? >>>> My recollection is that we agreed to drop DCEP, with the possibility to resurrect it if something goes wrong with the progression of the ejzak draft. >>> Ok. So, related to the discussion on whether CLUE is only for SIP, CLUE would at least require the usage of SDP, right? >> [CNG] For our work yes, however I don' think SDP is mandatory in all cases. So long as whatever ever is used to describe the encodings/bearer (e.g. H.245) contains a reference to the CLUE encodingID then I think CLUE can be used. > Sure. > > But, then, if you want to use DCEP for H.245, you would have to define that separately. Yes exactly, that work is currently being done in Q2 and q5 ITU-T SG16. Christian > > Regards, > > Christer > > From nobody Fri Jan 30 05:18:17 2015 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 AC0071A0366; Fri, 30 Jan 2015 05:18:00 -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 rSkhRBsB19kI; Fri, 30 Jan 2015 05:17:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C0D1A01F2; Fri, 30 Jan 2015 05:17:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130131759.8774.33719.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 05:17:59 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-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: Fri, 30 Jan 2015 13:18:01 -0000 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 : CLUE Protocol Data Channel Author : Christer Holmberg Filename : draft-ietf-clue-datachannel-07.txt Pages : 12 Date : 2015-01-30 Abstract: This document defines how to use the WebRTC Data Channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-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 nobody Fri Jan 30 05:20:33 2015 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 B67981A035F for ; Fri, 30 Jan 2015 05:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If_2lmMMUn7u for ; Fri, 30 Jan 2015 05:20:30 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9141A034F for ; Fri, 30 Jan 2015 05:20:29 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-d0-54cb851bf0c3 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.26.24955.B158BC45; Fri, 30 Jan 2015 14:20:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Fri, 30 Jan 2015 14:20:27 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: CLUE-data-channel-07 Thread-Index: AdA8j0xUpek2MFB+RZyrL9UInKeqsA== Date: Fri, 30 Jan 2015 13:20:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D68838A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D68838AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja506+kQgz8vtCz2n7rMbLFxp7YD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH/cW7BQemKmfMfszQwzpPoYuTkkBAwkTj4 7ho7hC0mceHeerYuRi4OIYEjjBKXH/5jgXAWM0os/nmZqYuRg4NNwEKi+582SIOIgLLE0c39 bCA2s4CXxLezv5lAbGEBA4lV7ZfYIGpMJeav380MYetJfPnfwghiswioSnxaOQ0szivgK7F+ 9hawXkagI76fWsMEMVNc4taT+UwQxwlILNlznhnCFpV4+fgfK4StJPFjwyUWiPp8iekzvjBB zBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxa nJSbbmSsl1qUmVxcnJ+nl5dasokRGDsHt/xW3cF4+Y3jIUYBDkYlHt4Nn0+FCLEmlhVX5h5i lOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBccqXXS9dpjssvtO+ovrjZ/Nn Dv9cQtrm3U6W+/XkeNcBlft+Wz+oz02qu84ns6pAdn2RTkcid4bRfh3e5cImoVMXWsu+SvKa 9sylNP6C/OX69dtXrKz8H7/v27z2rvop345ci1Z1fqTkzZP5iCVaOX5e6BOl298dfh7lsrJZ 9ODXzP1Ry4Il7iuxFGckGmoxFxUnAgACb/EGfgIAAA== Archived-At: Subject: [clue] Draft new version: CLUE-data-channel-07 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, 30 Jan 2015 13:20:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D68838AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version of the CLUE data channel draft, where the DCEP= procedures have been removed. I did add the following note to section 1: "NOTE: The usage of the Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE dat= a channel is outside the scope of this document." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D68838AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve submitted a new version of the CLUE data = channel draft, where the DCEP procedures have been removed.

 

I did add the following note to section 1:

 

“NOTE: The usage = of the Data Channel Establishment Protocol (DCEP)

         &nb= sp;      [I-D.ietf-rtcweb-data-protocol] for estab= lishing a CLUE data channel

         &nb= sp;      is outside the scope of this document.= 221;

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D68838AESESSMB209erics_-- From nobody Fri Jan 30 08:10:57 2015 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 044571A0439 for ; Fri, 30 Jan 2015 08:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RdYkK2s37O6O for ; Fri, 30 Jan 2015 08:10:54 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC3F1A1A15 for ; Fri, 30 Jan 2015 08:10:54 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id h11so4119477wiw.5 for ; Fri, 30 Jan 2015 08:10:53 -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=L7/AZ2wgURj8demZOIpFgr+EAjiyE2HaoUNuVNIGE1U=; b=SZEiHq1fRGdgx1xZBKf9vwIH+eqy5hvTXwEJCBsxqDAZ/80og+IZxQgOkROaWh3Frk thNJJNG4T2UN2fYHsga6u+pYFzq8U+ibC3aaxoCtsyfdr7yxklwV0P6XZVLaBUk4mTIJ 6Fi4hky6lrpIIiUgNRD37fiOqp7AbYFOEbi/+ySw7PI1R/4Gd8jFSTIy2249EKD54YOb L6PpDND6DqWJnfcST4g06QDqx9HfwLjeM+IxjbXDR2eXh9hHApnROnJZCWdLb7D5rWCJ boE2/ArTD6J4XyS7rTmj2CYbqZSUSjo0HKZJjpsEFpHO8pZBzu/BtPs20PAb5Pbk8+dK kJTw== MIME-Version: 1.0 X-Received: by 10.194.60.235 with SMTP id k11mr13345022wjr.131.1422634253260; Fri, 30 Jan 2015 08:10:53 -0800 (PST) Received: by 10.194.42.66 with HTTP; Fri, 30 Jan 2015 08:10:53 -0800 (PST) Date: Fri, 30 Jan 2015 11:10:53 -0500 Message-ID: From: Daniel Burnett To: clue@ietf.org Content-Type: multipart/alternative; boundary=047d7ba973c44f9c2d050de0d9d2 Archived-At: Subject: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February 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, 30 Jan 2015 16:10:56 -0000 --047d7ba973c44f9c2d050de0d9d2 Content-Type: text/plain; charset=UTF-8 To all CLUE participants, Other than dependencies there do not seem to be any major outstanding issues remaining for the data channel draft, so I am starting a WGLC today. The end of this WGLC will be end of the day (wherever you are) on Friday February 13. That gives two full weeks from today. If all is in order this will be the last review of this document by the WG before it goes to the ADs and the IESG. Now is the time for careful, thorough reviews of the full document. Thankfully, the document is very short and easy to read since it largely references other documents. Familiarity with both MMUSIC work and WebRTC data channels is a plus but not required. To help in planning, please respond to this message if you plan to submit a review. We can only move forward if we get reviews! And yes, I will be a doing a WGLC review of the draft myself :) -- dan (for all the chairs) --047d7ba973c44f9c2d050de0d9d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To all CLUE participants,

Other than dependencies t= here do not seem to be any major outstanding issues remaining for the data = channel draft, so I am starting a WGLC today.=C2=A0 The end of this WGLC wi= ll be end of the day (wherever you are) on Friday February 13. That gives t= wo full weeks from today.

If all is in order this will be the last r= eview of this document by the WG before it goes to the ADs and the IESG.=C2= =A0 Now is the time for careful, thorough reviews of the full document.=C2= =A0 Thankfully, the document is very short and easy to read since it largel= y references other documents.=C2=A0 Familiarity with both MMUSIC work and W= ebRTC data channels is a plus but not required.

To help in planning,= please respond to this message if you plan to submit a review.=C2=A0 We ca= n only move forward if we get reviews!

And yes, I will be a doing a = WGLC review of the draft myself :)

-- dan
(for all the chairs)
--047d7ba973c44f9c2d050de0d9d2--