From nobody Wed Oct 1 10:44:39 2014 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 7FAE11A1A67 for ; Wed, 1 Oct 2014 10:44:38 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 mQ-kH7cxIiMy for ; Wed, 1 Oct 2014 10:44:37 -0700 (PDT) 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 651291A1A8B for ; Wed, 1 Oct 2014 10:44:37 -0700 (PDT) Received: from [216.82.249.212:57673] by server-15.bemta-12.messagelabs.com id 5E/43-08334-48D3C245; Wed, 01 Oct 2014 17:44:36 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-219.messagelabs.com!1412185404!8935405!4 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32457 invoked from network); 1 Oct 2014 17:43:54 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 1 Oct 2014 17:43:54 -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; Wed, 1 Oct 2014 10:43:40 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 1 Oct 2014 10:43:40 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Wed, 1 Oct 2014 10:43:37 -0700 Thread-Topic: [clue] comments on draft-ietf-clue-data-model-schema-07 Thread-Index: Ac/c9gkQM7MkBH8HQyabFuqwBZjMrwAqNR8Q Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922FD5@CRPMBOXPRD08.polycom.com> References: <542B2164.1060207@alum.mit.edu> In-Reply-To: <542B2164.1060207@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: http://mailarchive.ietf.org/arch/msg/clue/k4y2-XSnswSTmMQyGTv1oEF_pg4 Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Wed, 01 Oct 2014 17:44:38 -0000 Paul wrote: > Why has the definition of Simultaneous Transmission Set been changed to > constrain to captures of the same type? I thought we explicitly agreed > that there should be no such restriction. I thought we explicitly agreed an STS has just a single media type. The fr= amework section 8 has this: =20 "This type of constraint is expressed in a Simultaneous Transmission Set, w= hich lists all the Captures of a particular media type (e.g. audio, video, = text) that can be sent at the same time. There are different Simultaneous = Transmission Sets for each media type in the Advertisement." Maybe you are thinking of Encoding Groups, which can have multiple media ty= pes in the same group? Mark From nobody Thu Oct 2 02:04:22 2014 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 2689C1A0211 for ; Thu, 2 Oct 2014 02:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.037 X-Spam-Level: X-Spam-Status: No, score=-0.037 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqhKK7fANPlU for ; Thu, 2 Oct 2014 02:04:19 -0700 (PDT) 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 21D9F1A0204 for ; Thu, 2 Oct 2014 02:04:19 -0700 (PDT) X-ASG-Debug-ID: 1412240656-05ce377d198ff9a0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id u3mzyPFoR7mxrDeR (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 02 Oct 2014 11:04:16 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s9294F5E030267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 11:04:16 +0200 Message-ID: <542D1517.4050803@unina.it> Date: Thu, 02 Oct 2014 11:04:23 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , CLUE References: <542B1BA9.30907@alum.mit.edu> X-ASG-Orig-Subj: Re: [clue] Question about draft-ietf-clue-data-model-schema-07 In-Reply-To: <542B1BA9.30907@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1412240656 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.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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10122 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VYRuWGmMz5GTZvg6-DfZq70_y1Y Subject: Re: [clue] Question about draft-ietf-clue-data-model-schema-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: Thu, 02 Oct 2014 09:04:21 -0000 Hello Paul, please see below. Il 30/09/2014 23:07, Paul Kyzivat ha scritto: > (I think this is really a basic xml question) > > The examples (in sections 23.1, 26, and 27) define media captures as > follows: > > > xsi:type="audioCaptureType" > captureID="AC0" > mediaType="audio"> > ... > > I was expecting something like: > > > > ... > > Is what is shown necessary because "audioCapture" isn't defined as an > element in the schema, though "audioCaptureType" is defined as a type? > > If was defined, would the two forms above be equivalent? > [RP] If you want something like: You need to change also the definition of the element, besides defining a new element called "audioCapture", otherwise you have a validation error. The new definition should envision a sequence of elements, followed by a sequence of elements, then followed by a sequence of generic media capture elements, i.e., you need to specify an order that the elements of different type must respect when listed in . Currently, collects captures without a specific order. Regards, Roberta > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 2 02:23:17 2014 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 A1B9D1A0218 for ; Thu, 2 Oct 2014 02:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76OBRQfOwHmA for ; Thu, 2 Oct 2014 02:23:09 -0700 (PDT) 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 958EC1A002D for ; Thu, 2 Oct 2014 02:23:08 -0700 (PDT) X-ASG-Debug-ID: 1412241785-05ce377d169022c0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id UlB7jt0EsevZAdzd (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 02 Oct 2014 11:23:05 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s929N1KT000535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 11:23:02 +0200 Message-ID: <542D197D.9040808@unina.it> Date: Thu, 02 Oct 2014 11:23:09 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , CLUE References: <542B2164.1060207@alum.mit.edu> X-ASG-Orig-Subj: Re: [clue] comments on draft-ietf-clue-data-model-schema-07 In-Reply-To: <542B2164.1060207@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------070902060200030504010607" X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1412241785 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.0200 1.0000 -1.8908 X-Barracuda-Spam-Score: -1.89 X-Barracuda-Spam-Status: No, SCORE=-1.89 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.10123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/OXXdW1UFaYTJYwiHVLoa9ZYmD-s Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 02 Oct 2014 09:23:15 -0000 This is a multi-part message in MIME format. --------------070902060200030504010607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Paul, thank you for the review. Please see the answers inline. Il 30/09/2014 23:32, Paul Kyzivat ha scritto: > Roberta, > > I tried to do a careful review of the schema again. The following are > my notes from that: > > * Terminology: > > Camera-Left and Right: this is now out of date with the -17 framework. > [RP] ok, this needs to be changed. > Why has the definition of Simultaneous Transmission Set been changed > to constrain to captures of the same type? I thought we explicitly > agreed that there should be no such restriction. [RP] This is text from framework 16, Section 8 (it appears also in framework 17, Section 8). " /This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. /" This is text from Mark's review of July 21, citing a your suggestion on the topic: "/simultaneousSetType -- the framework says "For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Entries and Capture Scenes". Looks like the data model allows using CSE for shorthand, but not Capture Scenes. So should there be a "sceneIDREF" element here? Also, as Paul noted in his review of the framework, there needs to be a way to identify the media type for an STS if it includes only scenes. I suggest adding a (or ) element to the simultaneousSetType, with the same meaning it has elsewhere. Then all the media captures referenced in the STS must be of that media type"// / I'm sorry if I missed something about that. What is the final decision? I can easily change the text and the XML definition in the document accordingly. > * : > > There is a sequence containing spatialInformation. But there are no > bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. > (Doesn't make sense to appear more than once.) > > That assumes it belongs in mediaCaptureType. While there is a single > type for , audio and video have differing > constraints on which parts of this may/must be present and which must > not. ISTM that the benefit of having a single type has been lost. > Perhaps there should just be separate spatial info types for audio and > video. > > Also, can somebody please remind me why we need an explicit notation > for nonSpatiallyDefinable? (Rather than simply omitting spatial > information.) > > Similarly, is there a reason why we need "individual" as an > alternative to to the MCC info? Couldn't we simply have MCC info as an > optional fields? > [RP] We use the element in the definition of mediaCaptureType instead of simply making the elements optional because it allows for a more precise construction of the elements in the XML. The choice element makes you understand by simply reading the schema that, for example, only if you are describing a MCC capture you can use the block of elements made by "policy", "content", "synchID", etc., otherwise you must not use them (i.e., you are describing an individual capture). It is a way to make explicit mutually exclusive ways of description. The choice construct also allows the receiver to know without any doubt that, for example, a capture is an individual one and not a multi-content one. If no one of the multi-content attributes is provided (they are all optional), the receiver has no way to be sure that the capture is an individual capture - it could be a MCC with no attributes specified. What do you think about this motivations? However, no problem with changing the definition and with providing guidance text in the document. > The optional field element "view" of type "viewType" is confusing > since we switched to the sceneView and globalView terminology. I think > we should come up with a new name for this. A couple of terms that > come to mind are: "contentType" or "subjectType". > [RP] I propose instead of , and subjectType instead of viewType. > * : > > I still find this, and the element "personType" of this type, to be > very confusing to read and think about. Can we find some less > confusing term for this? I'm tempted to suggest personRole, even > though I know our past discussions add a lot of baggage to this. Some > other terms that might work are: "personDuty", "personFunction", > "personJob". > [RP] Please note that "personTypeType" is the name of the type, and it is not the name of the XML element that will appear in the ADV. Indeed, in the ADV you will have just XML elements. If we change in , for example, you will have "personRoleType" instead of "personTypeType", but we are no more compliant in terminology with the framework - you will need to choose a new common name indicating the role of the person and to change both documents accordingly. > * Extensibility of enumerations: > > This came up on the call wrt sensitivityPatternType. But there are > several enumerations that probably have the same concern: > - personTypeType > - viewType > - presentationType > - mobilityType > - ? scaleType > > The usual ietf solution for extensibility is an IANA registry. That > would be in lieu of enumerating them in the schema. If we went that > way then the element would probably simply be of type string, and text > would say that the valid values are defined in a registry, and that if > a value is not understood it should be ignored. > [RP] Thank you for listing them. I'm not sure I understand correctly. Are you saying that we should define such types as string an saying that acceptable values are those registered with IANA? Then, if we need to extend these types with new values, we need to update the IANA registrations and nothing more. Right? > * : > > The name of this has troubled me for some time, because, once you add > lineOfCapturePoint it is no longer a point. As an alternative, how > about "captureOriginType"? (I don't love that, but I like it better > than what we have and haven't thought of anything better.) > [RP] We have put in the definition of in order to make invalid those documents presenting a element without a previous element. Indeed, a line of capture point makes no sense in absence of a capture point. Even if I see your point, I do not think that changing names is a good idea in this case (because of terminology consistency reasons). We could simply make a separate element for , by removing its definition from the body of the capture point, and adding the rules of the correct composition of the spatial information in the description text of the data model document (we loose the encapsulation of the rule "no line of capture point without capture point" in the schema). What do you think about it? > * : > > Why is the type of encID "string"? Shouldn't it be IDREF? > [RP] IDREF is used to refer to ID that are shown in the XML document created accordingly to the schema. Since individual encodings are not listed anymore in the XML document, and since the "original" individual encoding identifiers are written in SDP, you can not use the xs:IDREF type for them, otherwise you have a validation error. > * : > > IIUC there is a requirement that all the captureIDREFs included in one > list must be of the same mediaType. But this isn't stated. ISTM that > this should be stated. > [RP] I will correct after I have the confirmation about the first point (simultaneous sets). > * Sample of extensibility (section 23.1): > > > > This section says: > > The extension defines ... an > attribute for characterizing the captures belonging to an > "otherCaptureType" defined by the user. > > From this I infer that the recipient is expected to classify the > predefined capture types by their type, but that extension types are > to be classified using attributes/elements that fit within the "any" > atttributes/elements of otherCaptureType. > > Is that what is intended? It seems unnatural. Why can't extension > capture types be defined as extensions of mediaCaptureType, just like > the builtin ones are? > [RP] If we go that way (S1), I agree the classification needs to be made by means of specific attributes/elements, we should put them within the otherCaptureType. I mean, we should introduce a field saying at least the name of the extension. On the other hand, if you define a new type extending mediaCaptureType in another schema, and insert in the XML doc that new type of media capture, you obtain a validation error if you use the standard schema for the validation. That happens because the new media capture type is not recognized by using the "standard" xml schema only, and because you do not insert the new media capture in place of an elements. I think this is what you have in mind (S2): New XML schema ("extension" namespace prefix): [---] [---] XML document excerpt compliant with the new schema: [---] [---] [---] [---] This XML document is not compliant with standard schema because the xsi:type of the second media capture is not defined in the standard schema, so it is not recognizable, and the unknown element (the media capture of the unknown type) is not placed in correspondence of an element. You do not have any validation issue only if (i) you define in the extension schema a new element of the new type (like a of newCaptureType), and (ii) add in the definition, after the envisioned sequence of media captures (S3): Updated CLUE schema: New part for the new extension schema: New XML excerpt compliant with the extension schema (and with the updated CLUE schema): [---] [---] The second media capture can now be interpreted as an element appearing in the part of . However, in this way, the parser expects that any element can appear in the last part of , and not only elements of extended media capture type. Each approach has pros and cons. We will consider their effects also on the protocol usage and discuss them again in the next call if you agree. > * Nit - the xml schema isn't all consistently indented. > > [RP] Sorry for that, I will correct the problem. > Thanks, > Paul > Roberta --------------070902060200030504010607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Paul,
thank you for the review.
Please see the answers inline.

Il 30/09/2014 23:32, Paul Kyzivat ha scritto:
Roberta,

I tried to do a careful review of the schema again. The following are my notes from that:

* Terminology:

Camera-Left and Right: this is now out of date with the -17 framework.

[RP] ok, this needs to be changed.
Why has the definition of Simultaneous Transmission Set been changed to constrain to captures of the same type? I thought we explicitly agreed that there should be no such restriction.
[RP]

This is text from framework 16, Section 8 (it appears also in framework 17, Section 8).
" This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. "

This is text from Mark's review of July 21, citing a your suggestion on the topic:
"simultaneousSetType – the framework says “For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Entries and Capture Scenes”.  Looks like the data model allows using CSE for shorthand, but not Capture Scenes.  So should there be a “sceneIDREF” element here?  Also, as Paul noted in his review of the framework, there needs to be a way to identify the media type for an STS if it includes only scenes.  I suggest adding a <capturedMedia> (or <mediaType>) element to the simultaneousSetType, with the same meaning it has elsewhere.  Then all the media captures referenced in the STS must be of that media type"

I'm sorry if I missed something about that.
What is the final decision?
I can easily change the text and the XML definition in the document accordingly.

* <mediaCaptureType>:

There is a sequence containing spatialInformation. But there are no bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. (Doesn't make sense to appear more than once.)

That assumes it belongs in mediaCaptureType. While there is a single type for <spatialInformation>, audio and video have differing constraints on which parts of this may/must be present and which must not. ISTM that the benefit of having a single type has been lost. Perhaps there should just be separate spatial info types for audio and video.

Also, can somebody please remind me why we need an explicit notation for nonSpatiallyDefinable? (Rather than simply omitting spatial information.)

Similarly, is there a reason why we need "individual" as an alternative to to the MCC info? Couldn't we simply have MCC info as an optional fields?

[RP]
We use the <choice> element in the definition of mediaCaptureType instead of simply making the elements optional because it allows for a more precise construction of the <mediaCapture> elements in the XML.
The choice element makes you understand by simply reading the schema that, for example, only  if you are describing a MCC capture you can use the block of elements made by "policy", "content", "synchID", etc., otherwise you must not use them (i.e., you are describing an individual capture).
It is a way to make explicit mutually exclusive ways of description.
The choice construct also allows the receiver to know without any doubt that, for example, a capture is an individual one and not a multi-content one. If no one of the multi-content attributes is provided (they are all optional), the receiver has no way to be sure that the capture is an individual capture - it could be a MCC with no attributes specified.
What do you think about this motivations?
However, no problem with changing the definition and with providing guidance text in the document.

The optional field element "view" of type "viewType" is confusing since we switched to the sceneView and globalView terminology. I think we should come up with a new name for this. A couple of terms that come to mind are: "contentType" or "subjectType".

[RP] I propose <subject> instead of <view>, and subjectType instead of viewType.

* <personTypeType>:

I still find this, and the element "personType" of this type, to be very confusing to read and think about. Can we find some less confusing term for this? I'm tempted to suggest personRole, even though I know our past discussions add a lot of baggage to this. Some other terms that might work are: "personDuty", "personFunction", "personJob".

[RP]
Please note that "personTypeType" is the name of the type, and it is not the name of the XML element that will appear in the ADV. Indeed, in the ADV you will have just <personType> XML elements.
If we change <personType> in <personRole>, for example, you will have "personRoleType" instead of "personTypeType", but we are no more compliant in terminology with the framework - you will need to choose a new common name indicating the role of the person and to change both documents accordingly.

* Extensibility of enumerations:

This came up on the call wrt sensitivityPatternType. But there are several enumerations that probably have the same concern:
- personTypeType
- viewType
- presentationType
- mobilityType
- ? scaleType

The usual ietf solution for extensibility is an IANA registry. That would be in lieu of enumerating them in the schema. If we went that way then the element would probably simply be of type string, and text would say that the valid values are defined in a registry, and that if a value is not understood it should be ignored.

[RP]
Thank you for listing them.
I'm not sure I understand correctly.
Are you saying that we should define such types as string an saying that acceptable values are those registered with IANA?
Then, if we need to extend these types with new values, we need to update the IANA registrations and nothing more.
Right?

* <capturePointType>:

The name of this has troubled me for some time, because, once you add lineOfCapturePoint it is no longer a point. As an alternative, how about "captureOriginType"? (I don't love that, but I like it better than what we have and haven't thought of anything better.)

[RP]
We have put <lineOfCapturePoint> in the definition of <capturePoint> in order to make invalid those documents presenting a <lineOfCapturePoint> element without a previous <capturePoint> element. Indeed, a line of capture point makes no sense in absence of a capture point.
Even if I see your point, I do not think that changing names is a good idea in this case (because of terminology consistency reasons).
We could simply make a separate element for <lineOfCapturePoint>, by removing its definition from the body of the capture point, and adding the rules of the correct composition of the spatial information in the description text of the data model document (we loose the encapsulation of the rule "no line of capture point without capture point" in the schema).
What do you think about it?
 
* <encodingIDListType>:

Why is the type of encID "string"? Shouldn't it be IDREF?

[RP]
IDREF is used to refer to ID that are shown in the XML document created accordingly to the schema.
Since individual encodings are not listed anymore in the XML document, and since the "original" individual encoding identifiers are written in SDP, you can not use the xs:IDREF type for them, otherwise you have a validation error.
* <mediaCaptureIDListType>:

IIUC there is a requirement that all the captureIDREFs included in one list must be of the same mediaType. But this isn't stated. ISTM that this should be stated.

[RP] I will correct after I have the confirmation about the first point (simultaneous sets).

* Sample of extensibility (section 23.1):



This section says:

   The extension defines ... an
   attribute for characterizing the captures belonging to an
   "otherCaptureType" defined by the user.

From this I infer that the recipient is expected to classify the predefined capture types by their type, but that extension types are to be classified using attributes/elements that fit within the "any" atttributes/elements of otherCaptureType.

Is that what is intended? It seems unnatural. Why can't extension capture types be defined as extensions of mediaCaptureType, just like the builtin ones are?

[RP]
If we go that way (S1), I agree the classification needs to be made by means of specific attributes/elements, we should put them within the otherCaptureType.
I mean, we should introduce a field saying at least the name of the extension.

On the other hand, if you  define a new type extending mediaCaptureType in another schema, and insert in the XML doc that new type of media capture, you obtain a validation error if you use the standard schema for the validation. That happens because the new media capture type is not recognized by using the "standard" xml schema only, and because you do not insert the new media capture in place of an <any> elements.
I think this is what you have in mind (S2):

New XML schema ("extension" namespace prefix):
[---]
<!-- NEW CAPTURE TYPE -->
<xs:complexType name="newCaptureType">
 <xs:complexContent>
  <xs:extension base="tns:mediaCaptureType">
   <xs:sequence>         
    <xs:element name="newCaptureTypeFeature" type="xs:string"
    minOccurs="0"/> 
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:extension> 
 </xs:complexContent>
</xs:complexType>
[---]

XML document excerpt compliant with the new schema:

[---]
    <mediaCaptures>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="audioCaptureType"
        captureID="AC0"
        mediaType="audio">
            [---]
        </mediaCapture>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="extension:newCaptureType"
        captureID="NC1"
        mediaType="new type">
            [---]
        </mediaCapture>
    </mediaCaptures>
[---]

This XML document is not  compliant with standard schema because the xsi:type of the second media capture is not defined in the standard schema, so it is not recognizable, and the unknown element (the media capture of the unknown type) is not placed in correspondence of an <any> element.

You do not have any validation issue  only if (i) you define in the extension schema a new element of the new type (like a <newMediaCapture> of newCaptureType), and (ii) add  <any>  in the <mediaCaptures> definition, after the envisioned sequence of media captures (S3):

Updated CLUE schema:
<!-- MEDIA CAPTURES TYPE + ANY-->
<!-- envelope of media captures -->
<xs:complexType name="mediaCapturesType">            
 <xs:sequence>
   <xs:element name="mediaCapture" type="mediaCaptureType"
   maxOccurs="unbounded"/>          
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>
 </xs:sequence>           
</xs:complexType>

New part for the new extension schema:
<xs:element name="newMediaCapture" type="tns:newCaptureType"/>

New XML excerpt compliant with the extension schema (and with the updated CLUE schema):
    <mediaCaptures>
        <mediaCapture
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="audioCaptureType"
                captureID="AC0" mediaType="audio">
        [---]
        </mediaCapture>
        <ns3:newMediaCapture captureID="nc0" mediaType="new type">
        [---]
        </ns3:newMediaCapture>
    </mediaCaptures>

The second media capture can now be interpreted as an element appearing in the <any> part of <mediaCaptures>.
However, in this way, the parser expects that any element can appear in the last part of <mediaCaptures>, and not only elements of extended media capture type.

Each approach has pros and cons.
We will consider their effects also on the protocol usage and discuss them again in the next call if you agree.


* Nit - the xml schema isn't all consistently indented.


[RP] Sorry for that, I will correct the problem.
    Thanks,
    Paul

Roberta
--------------070902060200030504010607-- From nobody Thu Oct 2 05:07:36 2014 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 3FAA91A1BD2 for ; Thu, 2 Oct 2014 05:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.164 X-Spam-Level: * X-Spam-Status: No, score=1.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQl6tbwIyBC3 for ; Thu, 2 Oct 2014 05:07:22 -0700 (PDT) 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 B88A21A1ABA for ; Thu, 2 Oct 2014 05:07:21 -0700 (PDT) X-ASG-Debug-ID: 1412251634-05f275211f03d40008-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id jOwbAI94k8YQbROr; Thu, 02 Oct 2014 14:07:18 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s9291nRp009463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Oct 2014 11:01:50 +0200 Message-ID: <542D1485.6070602@unina.it> Date: Thu, 02 Oct 2014 11:01:57 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , CLUE References: <542B2164.1060207@alum.mit.edu> X-ASG-Orig-Subj: Re: [clue] comments on draft-ietf-clue-data-model-schema-07 In-Reply-To: <542B2164.1060207@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------000601040908040606070409" X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1412251638 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.10104 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TWxuVpXnmrpgu3LN9Xp2_u9062U Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 02 Oct 2014 12:07:30 -0000 This is a multi-part message in MIME format. --------------000601040908040606070409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Paul, thank you for the review. Please see the answers inline. Il 30/09/2014 23:32, Paul Kyzivat ha scritto: > Roberta, > > I tried to do a careful review of the schema again. The following are > my notes from that: > > * Terminology: > > Camera-Left and Right: this is now out of date with the -17 framework. > [RP] ok, this needs to be changed. > Why has the definition of Simultaneous Transmission Set been changed > to constrain to captures of the same type? I thought we explicitly > agreed that there should be no such restriction. [RP] This is text from framework 16, Section 8 (it appears also in framework 17, Section 8). " /This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. /" This is text from Mark's review of July 21, citing a your suggestion on the topic: "/simultaneousSetType -- the framework says "For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Entries and Capture Scenes". Looks like the data model allows using CSE for shorthand, but not Capture Scenes. So should there be a "sceneIDREF" element here? Also, as Paul noted in his review of the framework, there needs to be a way to identify the media type for an STS if it includes only scenes. I suggest adding a (or ) element to the simultaneousSetType, with the same meaning it has elsewhere. Then all the media captures referenced in the STS must be of that media type"// / I'm sorry if I missed something about that. What is the final decision? I can easily change the text and the XML definition in the document accordingly. > * : > > There is a sequence containing spatialInformation. But there are no > bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. > (Doesn't make sense to appear more than once.) > > That assumes it belongs in mediaCaptureType. While there is a single > type for , audio and video have differing > constraints on which parts of this may/must be present and which must > not. ISTM that the benefit of having a single type has been lost. > Perhaps there should just be separate spatial info types for audio and > video. > > Also, can somebody please remind me why we need an explicit notation > for nonSpatiallyDefinable? (Rather than simply omitting spatial > information.) > > Similarly, is there a reason why we need "individual" as an > alternative to to the MCC info? Couldn't we simply have MCC info as an > optional fields? > [RP] We use the element in the definition of mediaCaptureType instead of simply making the elements optional because it allows for a more precise construction of the elements in the XML. The choice element makes you understand by simply reading the schema that, for example, only if you are describing a MCC capture you can use the block of elements made by "policy", "content", "synchID", etc., otherwise you must not use them (i.e., you are describing an individual capture). It is a way to make explicit mutually exclusive ways of description. The choice construct also allows the receiver to know without any doubt that, for example, a capture is an individual one and not a multi-content one. If no one of the multi-content attributes is provided (they are all optional), the receiver has no way to be sure that the capture is an individual capture - it could be a MCC with no attributes specified. What do you think about this motivations? However, no problem with changing the definition and with providing guidance text in the document. > The optional field element "view" of type "viewType" is confusing > since we switched to the sceneView and globalView terminology. I think > we should come up with a new name for this. A couple of terms that > come to mind are: "contentType" or "subjectType". > [RP] I propose instead of , and subjectType instead of viewType. > * : > > I still find this, and the element "personType" of this type, to be > very confusing to read and think about. Can we find some less > confusing term for this? I'm tempted to suggest personRole, even > though I know our past discussions add a lot of baggage to this. Some > other terms that might work are: "personDuty", "personFunction", > "personJob". > [RP] Please note that "personTypeType" is the name of the type, and it is not the name of the XML element that will appear in the ADV. Indeed, in the ADV you will have just XML elements. If we change in , for example, you will have "personRoleType" instead of "personTypeType", but we are no more compliant in terminology with the framework - you will need to choose a new common name indicating the role of the person and to change both documents accordingly. > * Extensibility of enumerations: > > This came up on the call wrt sensitivityPatternType. But there are > several enumerations that probably have the same concern: > - personTypeType > - viewType > - presentationType > - mobilityType > - ? scaleType > > The usual ietf solution for extensibility is an IANA registry. That > would be in lieu of enumerating them in the schema. If we went that > way then the element would probably simply be of type string, and text > would say that the valid values are defined in a registry, and that if > a value is not understood it should be ignored. > [RP] Thank you for listing them. I'm not sure I understand correctly. Are you saying that we should define such types as string an saying that acceptable values are those registered with IANA? Then, if we need to extend these types with new values, we need to update the IANA registrations and nothing more. Right? > * : > > The name of this has troubled me for some time, because, once you add > lineOfCapturePoint it is no longer a point. As an alternative, how > about "captureOriginType"? (I don't love that, but I like it better > than what we have and haven't thought of anything better.) > [RP] We have put in the definition of in order to make invalid those documents presenting a element without a previous element. Indeed, a line of capture point makes no sense in absence of a capture point. Even if I see your point, I do not think that changing names is a good idea in this case (because of terminology consistency reasons). We could simply make a separate element for , by removing its definition from the body of the capture point, and adding the rules of the correct composition of the spatial information in the description text of the data model document (we loose the encapsulation of the rule "no line of capture point without capture point" in the schema). What do you think about it? > * : > > Why is the type of encID "string"? Shouldn't it be IDREF? > [RP] IDREF is used to refer to ID that are shown in the XML document created accordingly to the schema. Since individual encodings are not listed anymore in the XML document, and since the "original" individual encoding identifiers are written in SDP, you can not use the xs:IDREF type for them, otherwise you have a validation error. > * : > > IIUC there is a requirement that all the captureIDREFs included in one > list must be of the same mediaType. But this isn't stated. ISTM that > this should be stated. > [RP] I will correct after I have the confirmation about the first point (simultaneous sets). > * Sample of extensibility (section 23.1): > > > > This section says: > > The extension defines ... an > attribute for characterizing the captures belonging to an > "otherCaptureType" defined by the user. > > From this I infer that the recipient is expected to classify the > predefined capture types by their type, but that extension types are > to be classified using attributes/elements that fit within the "any" > atttributes/elements of otherCaptureType. > > Is that what is intended? It seems unnatural. Why can't extension > capture types be defined as extensions of mediaCaptureType, just like > the builtin ones are? > [RP] If we go that way (S1), I agree the classification needs to be made by means of specific attributes/elements, we should put them within the otherCaptureType. I mean, we should introduce a field saying at least the name of the extension. On the other hand, if you define a new type extending mediaCaptureType in another schema, and insert in the XML doc that new type of media capture, you obtain a validation error if you use the standard schema for the validation. That happens because the new media capture type is not recognized by using the "standard" xml schema only, and because you do not insert the new media capture in place of an elements. I think this is what you have in mind (S2): New XML schema ("extension" namespace prefix): [---] [---] XML document excerpt compliant with the new schema: [---] [---] [---] [---] This XML document is not compliant with standard schema because the xsi:type of the second media capture is not defined in the standard schema, so it is not recognizable, and the unknown element (the media capture of the unknown type) is not placed in correspondence of an element. You do not have any validation issue only if (i) you define in the extension schema a new element of the new type (like a of newCaptureType), and (ii) add in the definition, after the envisioned sequence of media captures (S3): Updated CLUE schema: New part for the new extension schema: New XML excerpt compliant with the extension schema (and with the updated CLUE schema): [---] [---] The second media capture can now be interpreted as an element appearing in the part of . However, in this way, the parser expects that any element can appear in the last part of , and not only elements of extended media capture type. Each approach has pros and cons. We will consider their effects also on the protocol usage and discuss them again in the next call if you agree. > * Nit - the xml schema isn't all consistently indented. > > [RP] Sorry for that, I will correct the problem. > Thanks, > Paul > Roberta --------------000601040908040606070409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Paul,
thank you for the review.
Please see the answers inline.

Il 30/09/2014 23:32, Paul Kyzivat ha scritto:
Roberta,

I tried to do a careful review of the schema again. The following are my notes from that:

* Terminology:

Camera-Left and Right: this is now out of date with the -17 framework.

[RP] ok, this needs to be changed.
Why has the definition of Simultaneous Transmission Set been changed to constrain to captures of the same type? I thought we explicitly agreed that there should be no such restriction.
[RP]

This is text from framework 16, Section 8 (it appears also in framework 17, Section 8).
" This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement. "

This is text from Mark's review of July 21, citing a your suggestion on the topic:
"simultaneousSetType – the framework says “For shorthand convenience, a Provider MAY describe a Simultaneous Transmission Set in terms of Capture Scene Entries and Capture Scenes”.  Looks like the data model allows using CSE for shorthand, but not Capture Scenes.  So should there be a “sceneIDREF” element here?  Also, as Paul noted in his review of the framework, there needs to be a way to identify the media type for an STS if it includes only scenes.  I suggest adding a <capturedMedia> (or <mediaType>) element to the simultaneousSetType, with the same meaning it has elsewhere.  Then all the media captures referenced in the STS must be of that media type"

I'm sorry if I missed something about that.
What is the final decision?
I can easily change the text and the XML definition in the document accordingly.

* <mediaCaptureType>:

There is a sequence containing spatialInformation. But there are no bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. (Doesn't make sense to appear more than once.)

That assumes it belongs in mediaCaptureType. While there is a single type for <spatialInformation>, audio and video have differing constraints on which parts of this may/must be present and which must not. ISTM that the benefit of having a single type has been lost. Perhaps there should just be separate spatial info types for audio and video.

Also, can somebody please remind me why we need an explicit notation for nonSpatiallyDefinable? (Rather than simply omitting spatial information.)

Similarly, is there a reason why we need "individual" as an alternative to to the MCC info? Couldn't we simply have MCC info as an optional fields?

[RP]
We use the <choice> element in the definition of mediaCaptureType instead of simply making the elements optional because it allows for a more precise construction of the <mediaCapture> elements in the XML.
The choice element makes you understand by simply reading the schema that, for example, only  if you are describing a MCC capture you can use the block of elements made by "policy", "content", "synchID", etc., otherwise you must not use them (i.e., you are describing an individual capture).
It is a way to make explicit mutually exclusive ways of description.
The choice construct also allows the receiver to know without any doubt that, for example, a capture is an individual one and not a multi-content one. If no one of the multi-content attributes is provided (they are all optional), the receiver has no way to be sure that the capture is an individual capture - it could be a MCC with no attributes specified.
What do you think about this motivations?
However, no problem with changing the definition and with providing guidance text in the document.

The optional field element "view" of type "viewType" is confusing since we switched to the sceneView and globalView terminology. I think we should come up with a new name for this. A couple of terms that come to mind are: "contentType" or "subjectType".

[RP] I propose <subject> instead of <view>, and subjectType instead of viewType.

* <personTypeType>:

I still find this, and the element "personType" of this type, to be very confusing to read and think about. Can we find some less confusing term for this? I'm tempted to suggest personRole, even though I know our past discussions add a lot of baggage to this. Some other terms that might work are: "personDuty", "personFunction", "personJob".

[RP]
Please note that "personTypeType" is the name of the type, and it is not the name of the XML element that will appear in the ADV. Indeed, in the ADV you will have just <personType> XML elements.
If we change <personType> in <personRole>, for example, you will have "personRoleType" instead of "personTypeType", but we are no more compliant in terminology with the framework - you will need to choose a new common name indicating the role of the person and to change both documents accordingly.

* Extensibility of enumerations:

This came up on the call wrt sensitivityPatternType. But there are several enumerations that probably have the same concern:
- personTypeType
- viewType
- presentationType
- mobilityType
- ? scaleType

The usual ietf solution for extensibility is an IANA registry. That would be in lieu of enumerating them in the schema. If we went that way then the element would probably simply be of type string, and text would say that the valid values are defined in a registry, and that if a value is not understood it should be ignored.

[RP]
Thank you for listing them.
I'm not sure I understand correctly.
Are you saying that we should define such types as string an saying that acceptable values are those registered with IANA?
Then, if we need to extend these types with new values, we need to update the IANA registrations and nothing more.
Right?

* <capturePointType>:

The name of this has troubled me for some time, because, once you add lineOfCapturePoint it is no longer a point. As an alternative, how about "captureOriginType"? (I don't love that, but I like it better than what we have and haven't thought of anything better.)

[RP]
We have put <lineOfCapturePoint> in the definition of <capturePoint> in order to make invalid those documents presenting a <lineOfCapturePoint> element without a previous <capturePoint> element. Indeed, a line of capture point makes no sense in absence of a capture point.
Even if I see your point, I do not think that changing names is a good idea in this case (because of terminology consistency reasons).
We could simply make a separate element for <lineOfCapturePoint>, by removing its definition from the body of the capture point, and adding the rules of the correct composition of the spatial information in the description text of the data model document (we loose the encapsulation of the rule "no line of capture point without capture point" in the schema).
What do you think about it?
 
* <encodingIDListType>:

Why is the type of encID "string"? Shouldn't it be IDREF?

[RP]
IDREF is used to refer to ID that are shown in the XML document created accordingly to the schema.
Since individual encodings are not listed anymore in the XML document, and since the "original" individual encoding identifiers are written in SDP, you can not use the xs:IDREF type for them, otherwise you have a validation error.
* <mediaCaptureIDListType>:

IIUC there is a requirement that all the captureIDREFs included in one list must be of the same mediaType. But this isn't stated. ISTM that this should be stated.

[RP] I will correct after I have the confirmation about the first point (simultaneous sets).

* Sample of extensibility (section 23.1):



This section says:

   The extension defines ... an
   attribute for characterizing the captures belonging to an
   "otherCaptureType" defined by the user.

From this I infer that the recipient is expected to classify the predefined capture types by their type, but that extension types are to be classified using attributes/elements that fit within the "any" atttributes/elements of otherCaptureType.

Is that what is intended? It seems unnatural. Why can't extension capture types be defined as extensions of mediaCaptureType, just like the builtin ones are?

[RP]
If we go that way (S1), I agree the classification needs to be made by means of specific attributes/elements, we should put them within the otherCaptureType.
I mean, we should introduce a field saying at least the name of the extension.

On the other hand, if you  define a new type extending mediaCaptureType in another schema, and insert in the XML doc that new type of media capture, you obtain a validation error if you use the standard schema for the validation. That happens because the new media capture type is not recognized by using the "standard" xml schema only, and because you do not insert the new media capture in place of an <any> elements.
I think this is what you have in mind (S2):

New XML schema ("extension" namespace prefix):
[---]
<!-- NEW CAPTURE TYPE -->
<xs:complexType name="newCaptureType">
 <xs:complexContent>
  <xs:extension base="tns:mediaCaptureType">
   <xs:sequence>         
    <xs:element name="newCaptureTypeFeature" type="xs:string"
    minOccurs="0"/> 
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>
   </xs:sequence>
   <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:extension> 
 </xs:complexContent>
</xs:complexType>
[---]

XML document excerpt compliant with the new schema:

[---]
    <mediaCaptures>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="audioCaptureType"
        captureID="AC0"
        mediaType="audio">
            [---]
        </mediaCapture>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:type="extension:newCaptureType"
        captureID="NC1"
        mediaType="new type">
            [---]
        </mediaCapture>
    </mediaCaptures>
[---]

This XML document is not  compliant with standard schema because the xsi:type of the second media capture is not defined in the standard schema, so it is not recognizable, and the unknown element (the media capture of the unknown type) is not placed in correspondence of an <any> element.

You do not have any validation issue  only if (i) you define in the extension schema a new element of the new type (like a <newMediaCapture> of newCaptureType), and (ii) add  <any>  in the <mediaCaptures> definition, after the envisioned sequence of media captures (S3):

Updated CLUE schema:
<!-- MEDIA CAPTURES TYPE + ANY-->
<!-- envelope of media captures -->
<xs:complexType name="mediaCapturesType">            
 <xs:sequence>
   <xs:element name="mediaCapture" type="mediaCaptureType"
   maxOccurs="unbounded"/>          
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
    maxOccurs="unbounded"/>
 </xs:sequence>           
</xs:complexType>

New part for the new extension schema:
<xs:element name="newMediaCapture" type="tns:newCaptureType"/>

New XML excerpt compliant with the extension schema (and with the updated CLUE schema):
    <mediaCaptures>
        <mediaCapture
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xsi:type="audioCaptureType"
                captureID="AC0" mediaType="audio">
        [---]
        </mediaCapture>
        <ns3:newMediaCapture captureID="nc0" mediaType="new type">
        [---]
        </ns3:newMediaCapture>
    </mediaCaptures>

The second media capture can now be interpreted as an element appearing in the <any> part of <mediaCaptures>.
However, in this way, the parser expects that any element can appear in the last part of <mediaCaptures>, and not only elements of extended media capture type.

Each approach has pros and cons.
We will consider their effects also on the protocol usage and discuss them again in the next call if you agree.


* Nit - the xml schema isn't all consistently indented.


[RP] Sorry for that, I will correct the problem.
    Thanks,
    Paul

Roberta
--------------000601040908040606070409-- From nobody Thu Oct 2 07:16:27 2014 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 7C3DE1A0365 for ; Thu, 2 Oct 2014 07:16:24 -0700 (PDT) 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 ziAumsHqQHDK for ; Thu, 2 Oct 2014 07:16:21 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FDB1A033D for ; Thu, 2 Oct 2014 07:16:21 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-06v.sys.comcast.net with comcast id yEG71o0084vw8ds01EGMHX; Thu, 02 Oct 2014 14:16:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id yEGL1o00C3Ge9ey01EGLGY; Thu, 02 Oct 2014 14:16:21 +0000 Message-ID: <542D5E34.7030103@alum.mit.edu> Date: Thu, 02 Oct 2014 10:16:20 -0400 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: Roberta Presta , CLUE References: <542B1BA9.30907@alum.mit.edu> <542D1517.4050803@unina.it> In-Reply-To: <542D1517.4050803@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412259381; bh=n+ifPtCDB3fCIPA59RwlSswZoBBBNA+K64gprbJi148=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o2D2BDs1Ueni2/10Herxn4NYJLtp7MD+UxU0GG0IgAyhkc9br/P99HGeuM/0kN1vL 5eyyVpbsoOHlGL5WpiatnUpZvHObGWl1g+ALQPGp8aH7fzXK92qkEPXm9zKvD1jFca U0HQ4aQbKanuaAGxkKgJJI0rvzDXioAgjHra/MvIkgl1fg2WdzaZ224pzxMVgzd5fo oPnBwxYYAQ5K58MkwXv9/z3KCUz0l8K9DK+ly/FnnVWn4jzAYRUBsFENY1I/clmjKy ZEmeH6PJsTrZK42iJG4GBNliZPxiBzkGAj1Cr94RnvP4x9ulpeBKwd887tXAJ2BD8T lHelhzmrg4j6w== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BVQ1TfdY4aanaUFCWFI3BnyHOwo Subject: Re: [clue] Question about draft-ietf-clue-data-model-schema-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: Thu, 02 Oct 2014 14:16:24 -0000 On 10/2/14 5:04 AM, Roberta Presta wrote: > Hello Paul, > please see below. > > > Il 30/09/2014 23:07, Paul Kyzivat ha scritto: >> (I think this is really a basic xml question) >> >> The examples (in sections 23.1, 26, and 27) define media captures as >> follows: >> >> >> > xsi:type="audioCaptureType" >> captureID="AC0" >> mediaType="audio"> >> ... >> >> I was expecting something like: >> >> >> >> ... >> >> Is what is shown necessary because "audioCapture" isn't defined as an >> element in the schema, though "audioCaptureType" is defined as a type? >> >> If was defined, would the two forms above be equivalent? >> > > [RP] > If you want something like: > > > You need to change also the definition of the element, > besides defining a new element called "audioCapture", otherwise you have > a validation error. > The new definition should envision a sequence of > elements, followed by a sequence of > elements, then followed by a sequence of generic media capture elements, > i.e., you need to specify an order that the elements of different type > must respect when listed in . > Currently, collects captures without a specific order. As you know, my understanding of xml is limited, so bear with me even if I am talking nonsense. Don't instances of type Y that extends type X qualify as instances of type X for purposes of validation? (Basic polymorphism.) You seem to be saying NO. If not, then what is the point of extension? And, what does: mean? I was guessing that, even though written as Regards, > > Roberta > >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From nobody Thu Oct 2 10:24:57 2014 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 1313A1A8A04 for ; Thu, 2 Oct 2014 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_25=0.6, 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 skgKatbajbHg for ; Thu, 2 Oct 2014 10:24:47 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1763A1A8951 for ; Thu, 2 Oct 2014 10:24:46 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-11v.sys.comcast.net with comcast id yHP01o00953iAfU01HQmwM; Thu, 02 Oct 2014 17:24:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id yHQl1o0033Ge9ey01HQlBk; Thu, 02 Oct 2014 17:24:46 +0000 Message-ID: <542D8A5C.5050004@alum.mit.edu> Date: Thu, 02 Oct 2014 13:24:44 -0400 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: Roberta Presta , CLUE References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> In-Reply-To: <542D197D.9040808@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1412270686; bh=i46jtGyqGn0JvmnMdOUMzAnCcRxTN9CHH4JeoASogPY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qkrpgtpdztd359CQGCLQX7NsxNcPRzmKzUzDPF0CMqOkt+VRmVGeBZS7vRE9NS/53 /OwByFQ89XHMRS8z9jb7K0IZ9i9oR76n/8Ke44OfmjVwOfliFKf4XEDUD6vVEAUcVe SUT56UOZhGGqevvqrSkwXgF+taID/q4VzWAl/NqGqUpV+/sv1PXXKO9M9hzDo5kNWv p/nQpyP9NuM0uFKNuZ5UKCgZKScjFk+/W56Mk79kc+pu3Bbj3JtJr2HaRMojHrd6Cx XSRnUvSMK8G0JGVWiFzvPtmhmcLyoSU8lKCEL1eHS7hSShXGHaVHtmzP/1rxtR1FcT G5bAfibp0cwxA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/AD7cA0MxRbVEkFht3t2gVavaGuo Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 02 Oct 2014 17:24:49 -0000 On 10/2/14 5:23 AM, Roberta Presta wrote: > Il 30/09/2014 23:32, Paul Kyzivat ha scritto: >> Why has the definition of Simultaneous Transmission Set been changed >> to constrain to captures of the same type? I thought we explicitly >> agreed that there should be no such restriction. > [RP] Mark also commented on this. I was mistaken. So forget about this comment. >> * : >> >> There is a sequence containing spatialInformation. But there are no >> bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. >> (Doesn't make sense to appear more than once.) >> >> That assumes it belongs in mediaCaptureType. While there is a single >> type for , audio and video have differing >> constraints on which parts of this may/must be present and which must >> not. ISTM that the benefit of having a single type has been lost. >> Perhaps there should just be separate spatial info types for audio and >> video. >> >> Also, can somebody please remind me why we need an explicit notation >> for nonSpatiallyDefinable? (Rather than simply omitting spatial >> information.) >> >> Similarly, is there a reason why we need "individual" as an >> alternative to to the MCC info? Couldn't we simply have MCC info as an >> optional fields? >> > [RP] > We use the element in the definition of mediaCaptureType > instead of simply making the elements optional because it allows for a > more precise construction of the elements in the XML. > The choice element makes you understand by simply reading the schema > that, for example, only if you are describing a MCC capture you can use > the block of elements made by "policy", "content", "synchID", etc., > otherwise you must not use them (i.e., you are describing an individual > capture). I wasn't questioning the use of the choice. Here is the part in question: IIUC, since it specifies neither maxoccurs nor minoccurs, this is just a more complex way of saying: > It is a way to make explicit mutually exclusive ways of description. > The choice construct also allows the receiver to know without any doubt > that, for example, a capture is an individual one and not a > multi-content one. If no one of the multi-content attributes is provided > (they are all optional), the receiver has no way to be sure that the > capture is an individual capture - it could be a MCC with no attributes > specified. > What do you think about this motivations? > However, no problem with changing the definition and with providing > guidance text in the document. OK. Now I understand the reason for "individual". But the same logic doesn't apply for nonSpatiallyDefinable. That is redundant with simply noting the absence of spatialInformation. >> The optional field element "view" of type "viewType" is confusing >> since we switched to the sceneView and globalView terminology. I think >> we should come up with a new name for this. A couple of terms that >> come to mind are: "contentType" or "subjectType". >> > [RP] I propose instead of , and subjectType instead of > viewType. WFM >> * : >> >> I still find this, and the element "personType" of this type, to be >> very confusing to read and think about. Can we find some less >> confusing term for this? I'm tempted to suggest personRole, even >> though I know our past discussions add a lot of baggage to this. Some >> other terms that might work are: "personDuty", "personFunction", >> "personJob". >> > [RP] > Please note that "personTypeType" is the name of the type, and it is not > the name of the XML element that will appear in the ADV. Indeed, in the > ADV you will have just XML elements. > If we change in , for example, you will have > "personRoleType" instead of "personTypeType", but we are no more > compliant in terminology with the framework - you will need to choose a > new common name indicating the role of the person and to change both > documents accordingly. OK. I'll just shut up again. >> * Extensibility of enumerations: >> >> This came up on the call wrt sensitivityPatternType. But there are >> several enumerations that probably have the same concern: >> - personTypeType >> - viewType >> - presentationType >> - mobilityType >> - ? scaleType >> >> The usual ietf solution for extensibility is an IANA registry. That >> would be in lieu of enumerating them in the schema. If we went that >> way then the element would probably simply be of type string, and text >> would say that the valid values are defined in a registry, and that if >> a value is not understood it should be ignored. >> > [RP] > Thank you for listing them. > I'm not sure I understand correctly. > Are you saying that we should define such types as string an saying that > acceptable values are those registered with IANA? > Then, if we need to extend these types with new values, we need to > update the IANA registrations and nothing more. > Right? Yes. I'm offering that as one approach for handling the extensibility of these fields. But it seems a little odd in xml, so I'm certainly open to other approaches that are more natural for xml, if there are any. >> * : I'll comment separately on this. >> * : >> >> Why is the type of encID "string"? Shouldn't it be IDREF? >> > [RP] > IDREF is used to refer to ID that are shown in the XML document created > accordingly to the schema. > Since individual encodings are not listed anymore in the XML document, > and since the "original" individual encoding identifiers are written in > SDP, you can not use the xs:IDREF type for them, otherwise you have a > validation error. Ahh! OK. That makes sense. >> * Sample of extensibility (section 23.1): I'll also comment on this separately. Thanks, Paul From nobody Fri Oct 3 07:10:55 2014 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 7457B1A0364 for ; Fri, 3 Oct 2014 07:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.365 X-Spam-Level: *** X-Spam-Status: No, score=3.365 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 222icbl_1PhI for ; Fri, 3 Oct 2014 07:10:48 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.2]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27AC1A1AEB for ; Fri, 3 Oct 2014 07:10:44 -0700 (PDT) Received: from [216.82.249.212:50445] by server-2.bemta-12.messagelabs.com id 72/25-10047-46EAE245; Fri, 03 Oct 2014 14:10:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-219.messagelabs.com!1412345443!15538911!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15518 invoked from network); 3 Oct 2014 14:10:44 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-3.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 3 Oct 2014 14:10:44 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 3 Oct 2014 07:10:43 -0700 From: "Duckworth, Mark" To: Roberta Presta , "clue@ietf.org" Date: Fri, 3 Oct 2014 07:10:41 -0700 Thread-Topic: [clue] pre-WGLC comments on data model Thread-Index: Ac/cCpQfr5JcIOOsS1SzkopVfBgKzwDAOR1w Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA969C3@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034@CRPMBOXPRD08.polycom.com> <54299663.1030007@unina.it> In-Reply-To: <54299663.1030007@unina.it> 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_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA969C3CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wzUF8bqfIEKd3GRnUK1EVZDrVkY Subject: Re: [clue] pre-WGLC comments on data model 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, 03 Oct 2014 14:10:51 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA969C3CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roberta, Thanks for the response to my comments. I have just a couple more comments below, I cut out the rest. Mark From: Roberta Presta [mailto:roberta.presta@unina.it] Sent: Monday, September 29, 2014 1:27 PM To: Duckworth, Mark; clue@ietf.org Cc: Simon Pietro Romano Subject: Re: [clue] pre-WGLC comments on data model "pointType" - I think we should avoid using numeric types that don't have a= range limit. How about using "xs:int" instead of "xs:decimal"? I was ass= uming we do not need to represent fractional millimeters here, I was always= assuming an int type. If people think we need to represent fractions, the= n should we use xs:float instead of xs:decimal? [RP] No problem with changing the type. We prefer xs:float instead of xs:de= cimal. [Duckworth, Mark] Okay, xs:float is good, but the document still says xs:de= cimal. Do we all agree we should not use numeric types that don't have a r= ange limit? "sceneEntryType" - is the schema for this missing an attribute called "medi= aType"? This is described in section 15.3, but I don't see it in the schem= a. [RP] Please see the mediaType issue above. Do you think we still need it? [Duckworth, Mark] No, we don't need it. draft -07 removed the section from= draft-06 that was "15.3 mediaType attribute", so it looks good now. --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA969C3CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Roberta,

Thanks = for the response to my comments.

= I have just a couple more comments below, I cut out the rest.

Mark

 

From: Roberta Presta [mail= to:roberta.presta@unina.it]
Sent: Monday, September 29, 2014 1:2= 7 PM
To: Duckworth, Mark; clue@ietf.org
Cc: Simon Pietr= o Romano
Subject: Re: [clue] pre-WGLC comments on data model=

 

“pointType” - I think we should avoid using numeric typ= es that don’t have a range limit.  How about using “xs:int= ” instead of “xs:decimal”?  I was assuming we do not= need to represent fractional millimeters here, I was always assuming an in= t type.  If people think we need to represent fractions, then should w= e use xs:float instead of xs:decimal?

[RP] No problem with changing the type. We prefer xs:float instead of x= s:decimal.

[D= uckworth, Mark] Okay, xs:float is good, but the document still says xs:deci= mal.  Do we all agree we should not use numeric types that don’t= have a range limit? 

“scene= EntryType” – is the schema for this missing an attribute called= “mediaType”?  This is described in section 15.3, but I do= n’t see it in the schema.

[R= P] Please see the mediaType issue above. Do you think we still need it?

 

[Duckworth, Mark] No, we don’t need it.  draft -07 removed th= e section from draft-06 that was “15.3 mediaType attribute”, so= it looks good now.

 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA969C3CRPMBOXPRD08p_-- From nobody Sat Oct 4 05:33:38 2014 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 C14D21A0070 for ; Sat, 4 Oct 2014 05:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 bLhOABa-9fDf for ; Sat, 4 Oct 2014 05:33:35 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21C51A005D for ; Sat, 4 Oct 2014 05:33:35 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-05v.sys.comcast.net with comcast id z0Zb1o0014zp9eg010ZboQ; Sat, 04 Oct 2014 12:33:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-07v.sys.comcast.net with comcast id z0ZZ1o00J3Ge9ey010Zaft; Sat, 04 Oct 2014 12:33:34 +0000 Message-ID: <542FE91D.3000408@alum.mit.edu> Date: Sat, 04 Oct 2014 08:33:33 -0400 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: "Duckworth, Mark" , CLUE References: <542B2164.1060207@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922FD5@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922FD5@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=1412426015; bh=Q/Z5a7Ppupo2a/rUsIqmzAlKySpF66iLX3MHAlMmn+I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tjmTi3AnoFaOVHGVHAI2+ggN+6cAHV0loUSBDK2jesEGokxbQpJ3p0bF+7no1i37u nbCpjdbg1UCvY373plAfyqkSFdwcHPWQDE1m/wSvUwjgMUAyuCWvfB//pFWWjxEI/Z w2eiIlfOHCPY4FwY+A36U7f/hlwQfr7R7uX9p8ucSLpyuTgfX7bad9IiOhYVQuLTIe Pdbzn/Z57VdSMkfRLjLjoeVRHNg2FazHjGmV7aaFEkqViJAkgXlTb8yXQeAFopspZL f0SlG3BvWEIidLIb2pqAeMwcmuQUW1LaaAlJSkOdjrgrgOWYsq/Vo3k4f7SD5swtGm USicTEwUQdnig== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/geN-aFrgVpyKO-7FCTZMiO2SXUc Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Sat, 04 Oct 2014 12:33:36 -0000 On 10/1/14 1:43 PM, Duckworth, Mark wrote: > Paul wrote: > >> Why has the definition of Simultaneous Transmission Set been changed to >> constrain to captures of the same type? I thought we explicitly agreed >> that there should be no such restriction. > > I thought we explicitly agreed an STS has just a single media type. The framework section 8 has this: > > "This type of constraint is expressed in a Simultaneous Transmission Set, which lists all the Captures of a particular media type (e.g. audio, video, text) that can be sent at the same time. There are different Simultaneous Transmission Sets for each media type in the Advertisement." > > Maybe you are thinking of Encoding Groups, which can have multiple media types in the same group? oh, duh! You are right - I mixed those up. Thanks, Paul From nobody Sun Oct 5 21:12:43 2014 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 E5BB61A1B1E for ; Sun, 5 Oct 2014 21:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7xUCbYjuFNs for ; Sun, 5 Oct 2014 21:12:40 -0700 (PDT) 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 8391E1A1B1D for ; Sun, 5 Oct 2014 21:12:40 -0700 (PDT) Received: from ppp118-209-167-95.lns20.mel8.internode.on.net ([118.209.167.95]:57778 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XazeG-0002J0-HI for clue@ietf.org; Mon, 06 Oct 2014 15:11:48 +1100 Message-ID: <543216B5.8080606@nteczone.com> Date: Mon, 06 Oct 2014 15:12:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> In-Reply-To: <542D8A5C.5050004@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/z0wSw9uA07Kfm7Q3e3-Ar9LVDoI Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Mon, 06 Oct 2014 04:12:42 -0000 Hello Roberta, Please see my replies below. Regards, Christian ..snip.. > >>> The optional field element "view" of type "viewType" is confusing >>> since we switched to the sceneView and globalView terminology. I think >>> we should come up with a new name for this. A couple of terms that >>> come to mind are: "contentType" or "subjectType". >>> >> [RP] I propose instead of , and subjectType instead of >> viewType. > > WFM [CNG] I don't really agree with the use of "subject". When I read "subject" I immediately think of what the conference is about. When I read "view" I think of what I am seeing/hearing. I think the fact that we use "sceneView" and "globalView" actually strengthens the reason we'd use the term "view". To distinguish we could add capture i.e. "captureView" "captureViewType". > ..snip.. >>> * Extensibility of enumerations: >>> >>> This came up on the call wrt sensitivityPatternType. But there are >>> several enumerations that probably have the same concern: >>> - personTypeType >>> - viewType >>> - presentationType >>> - mobilityType >>> - ? scaleType >>> >>> The usual ietf solution for extensibility is an IANA registry. That >>> would be in lieu of enumerating them in the schema. If we went that >>> way then the element would probably simply be of type string, and text >>> would say that the valid values are defined in a registry, and that if >>> a value is not understood it should be ignored. >>> >> [RP] >> Thank you for listing them. >> I'm not sure I understand correctly. >> Are you saying that we should define such types as string an saying that >> acceptable values are those registered with IANA? >> Then, if we need to extend these types with new values, we need to >> update the IANA registrations and nothing more. >> Right? > > Yes. I'm offering that as one approach for handling the extensibility > of these fields. But it seems a little odd in xml, so I'm certainly > open to other approaches that are more natural for xml, if there are any. [CNG] What i'd really like to see as part of the protocol document is an appendix with a template of exactly what a new registration would look like. I'd like to see that updates to CLUE can be made quickly without 1+ year of specification effort. Rather than registering new values with IANA, we can register the new "option" with IANA. e.g. in Megaco we register the PackageID with IANA which effectively points to a template for values/procedures. > From nobody Mon Oct 6 19:53:51 2014 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 127FF1A9117 for ; Mon, 6 Oct 2014 19:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k1IiMOe9S4k for ; Mon, 6 Oct 2014 19:53:45 -0700 (PDT) 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 4A6001A9116 for ; Mon, 6 Oct 2014 19:53:45 -0700 (PDT) Received: from ppp118-209-221-91.lns20.mel8.internode.on.net ([118.209.221.91]:55576 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XbKtE-0006qe-GK for clue@ietf.org; Tue, 07 Oct 2014 13:52:40 +1100 Message-ID: <543355B5.6040306@nteczone.com> Date: Tue, 07 Oct 2014 13:53:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/f72dgK-3Dw1M-4joPNyEFNwTHWo Subject: [clue] Design team meeting on protocols 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, 07 Oct 2014 02:53:47 -0000 Hello, I won't be able to attend the design team meeting. The recent daylight saving time change means it's too late for my part of the world. A couple of comments that might be relevant to discussions: 1) I still have an issue with the use of READV ACK for returning CLUE Info. The main issue is how to return an error if there's a fault in the CLUEinfo? e.g. for an Advertisement the MC can send a NACK indicating an error. I think its simply cleaner to always use an Advertisement to provide CLUE info. 2) With regards to the open ticket on partial updates, I provided draft-groves-clue-partial-update-00 to address this by presenting how partial updates could be done. I haven't received any feedback on this. Regards, Christian From nobody Tue Oct 7 07:42:51 2014 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 477B11A1BB4 for ; Tue, 7 Oct 2014 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 6cWyI5cz3iPm for ; Tue, 7 Oct 2014 07:42:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 6EE7B1A6F90 for ; Tue, 7 Oct 2014 07:42:47 -0700 (PDT) Received: from localhost ([::1]:56015 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbVyO-0007wh-80; Tue, 07 Oct 2014 07:42:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 07 Oct 2014 14:42:44 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/13#comment:6 Message-ID: <083.d395ea353a30c7d17b08e14a6318d496@trac.tools.ietf.org> References: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <068.5c6abb800fdf8cf51ba44786e2a839e4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HrcCxIKV4ody3NqRndiPy2aMlK8 Cc: clue@ietf.org Subject: Re: [clue] #13 (draft-ietf-clue-protocol): CLUE Protocol: What data needs to be in CLUE specific signaling? 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: Tue, 07 Oct 2014 14:42:49 -0000 #13: CLUE Protocol: What data needs to be in CLUE specific signaling? Changes (by pkyzivat@alum.mit.edu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | protocol-authors@tools.ietf.org Type: task | Status: closed Priority: blocker | Milestone: milestone1 Component: draft-ietf-clue- | Version: protocol | Resolution: fixed Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Tue Oct 7 07:45:36 2014 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 071FA1ACDB3 for ; Tue, 7 Oct 2014 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 4F7HnQRLNFVI for ; Tue, 7 Oct 2014 07:45:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 E2EFB1ACDB1 for ; Tue, 7 Oct 2014 07:45:30 -0700 (PDT) Received: from localhost ([::1]:56117 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbW13-0000A3-Mo; Tue, 07 Oct 2014 07:45:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 07 Oct 2014 14:45:29 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/20#comment:9 Message-ID: <083.ffba74eb2d83cac911e95a576a47d287@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PwNkKgjvdWXnB3zJZGxRBsgwMUU Cc: clue@ietf.org Subject: Re: [clue] #20 (draft-ietf-clue-protocol): Action item vii: Rejecting Configure 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: Tue, 07 Oct 2014 14:45:33 -0000 #20: Action item vii: Rejecting Configure Changes (by pkyzivat@alum.mit.edu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | protocol-authors@tools.ietf.org Type: task | Status: closed Priority: major | Milestone: Component: draft-ietf-clue- | Version: protocol | Resolution: fixed Severity: Candidate WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Tue Oct 7 07:47:03 2014 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 597671A1BB4 for ; Tue, 7 Oct 2014 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 TYpneuJbGgtx for ; Tue, 7 Oct 2014 07:47:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 DD1361ACDDC for ; Tue, 7 Oct 2014 07:46:56 -0700 (PDT) Received: from localhost ([::1]:56168 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1XbW2R-0001Kq-K8; Tue, 07 Oct 2014 07:46:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu X-Trac-Project: clue Date: Tue, 07 Oct 2014 14:46:55 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/44#comment:6 Message-ID: <083.28e16826defc0b934230ec7ed6161fc4@trac.tools.ietf.org> References: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-protocol-authors@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/k3FZfUIuhyvXj5nlEk5VusAMnFQ Cc: clue@ietf.org Subject: Re: [clue] #44 (draft-ietf-clue-protocol): CLUE Protocol: Remove contradiction wrt responding to Advertisement with Configure 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: Tue, 07 Oct 2014 14:47:01 -0000 #44: CLUE Protocol: Remove contradiction wrt responding to Advertisement with Configure Changes (by pkyzivat@alum.mit.edu): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | protocol-authors@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: Component: draft-ietf-clue- | Version: protocol | Resolution: fixed Severity: Active WG Document | Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Fri Oct 10 15:08:25 2014 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 572291A882B for ; Fri, 10 Oct 2014 15:08:22 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 BvpiglbQ1_-P for ; Fri, 10 Oct 2014 15:08:19 -0700 (PDT) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8E31A8743 for ; Fri, 10 Oct 2014 15:08:18 -0700 (PDT) Received: from [216.82.241.100:36288] by server-11.bemta-8.messagelabs.com id 0F/5A-25814-1D858345; Fri, 10 Oct 2014 22:08:17 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-220.messagelabs.com!1412978896!14387932!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24545 invoked from network); 10 Oct 2014 22:08:17 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-7.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 10 Oct 2014 22:08:17 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 10 Oct 2014 15:08:16 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 10 Oct 2014 15:08:14 -0700 Thread-Topic: [clue] comments on draft-ietf-clue-data-model-schema-07 Thread-Index: Ac/hG8jk0gtBBOpnSnWEAGKqZwJUfADuh2SQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970E3@CRPMBOXPRD08.polycom.com> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> In-Reply-To: <543216B5.8080606@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: http://mailarchive.ietf.org/arch/msg/clue/QvMOYus8watxZ70B4Kecdto-Nuw Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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, 10 Oct 2014 22:08:22 -0000 inline > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Monday, October 06, 2014 12:13 AM > To: clue@ietf.org > Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-07 >=20 > Hello Roberta, >=20 > Please see my replies below. >=20 > Regards, Christian >=20 > ..snip.. > > > >>> The optional field element "view" of type "viewType" is confusing > >>> since we switched to the sceneView and globalView terminology. I thin= k > >>> we should come up with a new name for this. A couple of terms that > >>> come to mind are: "contentType" or "subjectType". > >>> > >> [RP] I propose instead of , and subjectType instead of > >> viewType. > > > > WFM > [CNG] I don't really agree with the use of "subject". When I read > "subject" I immediately think of what the conference is about. When I > read "view" I think of what I am seeing/hearing. I think the fact that > we use "sceneView" and "globalView" actually strengthens the reason we'd > use the term "view". To distinguish we could add capture i.e. > "captureView" "captureViewType". [Duckworth, Mark] I agree with Christian. Similarly, I suggest the MCC related elements (name=3D"content" type=3D"con= tentType") would be easier to understand if we change the name to (name=3D"= mccContent" type=3D"mccContentType"). And also change name=3D"configuredCo= ntent" to name=3D"mccConfiguredContent" in the captureEncodingType. > > ..snip.. From nobody Fri Oct 10 15:20:47 2014 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 D6E431AD44C for ; Fri, 10 Oct 2014 15:20:42 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8RMpWRpaW5X4 for ; Fri, 10 Oct 2014 15:20:36 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2511A88C5 for ; Fri, 10 Oct 2014 15:20:15 -0700 (PDT) Received: from [216.82.249.212:2353] by server-6.bemta-12.messagelabs.com id 56/EB-11230-E9B58345; Fri, 10 Oct 2014 22:20:14 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-219.messagelabs.com!1412979614!12339362!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27595 invoked from network); 10 Oct 2014 22:20:14 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-6.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 10 Oct 2014 22:20:14 -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; Fri, 10 Oct 2014 15:20:14 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 10 Oct 2014 15:20:13 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 10 Oct 2014 15:20:11 -0700 Thread-Topic: [clue] Updates in framework-17 Thread-Index: Ac/cJ6xj2sKKTL2gT62cKLYDrGDapQIr86dg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970EB@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922CB4@CRPMBOXPRD08.polycom.com> <5429C727.7070407@alum.mit.edu> In-Reply-To: <5429C727.7070407@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: http://mailarchive.ietf.org/arch/msg/clue/Xxs3OqeH0LSaOCyUifJ58RGthRE Subject: Re: [clue] Updates in framework-17 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, 10 Oct 2014 22:20:43 -0000 Thanks Paul. comments inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, September 29, 2014 4:55 PM > To: clue@ietf.org > Subject: Re: [clue] Updates in framework-17 >=20 > A few comments on the changes in this version: >=20 > Section 3: >=20 > Global View: A set of references to one or more Capture Scene Views > of the same media type that are defined within scenes of the same > advertisement. Each Global View in the list is a suggestion from > the Provider to the Consumer for which CSVs provide a complete > representation of the simultaneous captures provided by the > Provider, across multiple scenes. >=20 > This has munged two things into one. It is in part a definition of > Global View and in part a definition of Global View List. I think both > should be in the definitions. [Duckworth, Mark] How about this: Global View: A set of references to one or more Capture Scene Views of the same media type that are defined within scenes of the same Advertisement. A Global View is a suggestion from the Provider to the Consumer for which CSVs provide a complete representation of the simultaneous captures provided by the Provider, across multiple scenes. Global View List: A list of Global Views included in an Advertisement. >=20 > Media Consumer: a CLUE-capable device that that is capable of > receiving Capture Encodings >=20 > Media Provider: a CLUE-capable device that is capable of sending > Capture Encodings >=20 > I wonder if these defs should say "a CLUE-enabled* device. [Duckworth, Mark] We don't have a definition for "CLUE-enabled device". Wo= uld that be "a CLUE-capable device in a CLUE-enabled call"? > Figure 1: >=20 > While this shows the Global View List, it doesn't show any Global Views. > Ideally it would - each referencing Scene Views. But it may be hard to > fit all that into the single diagram. [Duckworth, Mark] I could make a separate diagram to show just Scenes, CSV= s, Global Views, and a Global View List if you think that would be helpful. From nobody Sat Oct 11 10:23:13 2014 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 334541A6FE0 for ; Sat, 11 Oct 2014 10:23:11 -0700 (PDT) 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 Mr1EIQlAVc2y for ; Sat, 11 Oct 2014 10:23:09 -0700 (PDT) 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 DD4701A6FE5 for ; Sat, 11 Oct 2014 10:23:08 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-96-5439677ae83d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.36.21334.A7769345; Sat, 11 Oct 2014 19:23:06 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Sat, 11 Oct 2014 19:23:06 +0200 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: CLUE Data Channel: Why mandate support of SCTP interleaving? Thread-Index: Ac/ld9UgFZPn5qeDTN6TlsuzGX88XA== Date: Sat, 11 Oct 2014 17:23:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D476E06@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D476E06ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW5VumWIQd8SS4v9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoErY16nWsF6iYqdXw+zNDCuF+1i5OSQEDCR2NjwlRnCFpO4cG89 G4gtJHCUUaKhQaqLkQvIXgJkf5nM2MXIwcEmYCHR/U8bpEZEQFni6OZ+sHphAVeJyVvnsULE vSQe3r/HCGHrSSxe+YkFpJVFQFXiyE0WkDCvgK/EiykLmEBsRqC130+tAbOZBcQlbj2ZzwRx joDEkj3noU4TlXj5+B8rhK0ksfbwdhaI+nyJH5eOsUHMFJQ4OfMJywRGoVlIRs1CUjYLSRlE XEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREY DQe3/Nbdwbj6teMhRgEORiUeXoV+ixAh1sSy4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYwLHI6FP/wa1X1qy5opT9VenMHcesihJG51VF27jqJqjVW7dfmjlt 0hP3GMbm01ZrVS74MsxjWlK+wKMuJNDIOurUeQHHy6m7Hp97dPjcofotZ8xjLoa/UdSbdqk5 rChZu3GZH1PXtsozSh12E463r2IMePsm5ZEIw/KrH3wP90b7KG/68EpMiaU4I9FQi7moOBEA 8Lcp0mcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Gv3HIFGMXR1NEwkkGM4-fmTLf1w Subject: [clue] CLUE Data Channel: Why mandate support of SCTP interleaving? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 17:23:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D476E06ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I received a question on my the CLUE data channel spec mandates the support= of SCTP interleaving. In the core data channel spec support is a SHOULD. As far as I remember, we didn't have any real discussion about it - it was = just suggested and added to the draft :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D476E06ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I received a question on my the CLUE data channel sp= ec mandates the support of SCTP interleaving. In the core data channel spec= support is a SHOULD.

 

As far as I remember, we didn’t have any real = discussion about it – it was just suggested and added to the draft :)=

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D476E06ESESSMB209erics_-- From nobody Sat Oct 11 13:16:39 2014 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 BD0111A8789 for ; Sat, 11 Oct 2014 13:16:38 -0700 (PDT) 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 KY2ejMlqJGAJ for ; Sat, 11 Oct 2014 13:16:37 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37F51A877F for ; Sat, 11 Oct 2014 13:16:37 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-03v.sys.comcast.net with comcast id 1wGE1p006516pyw01wGcQ8; Sat, 11 Oct 2014 20:16:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id 1wGc1p0013Ge9ey01wGcPh; Sat, 11 Oct 2014 20:16:36 +0000 Message-ID: <54399023.5070501@alum.mit.edu> Date: Sat, 11 Oct 2014 16:16:35 -0400 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: <7594FB04B1934943A5C02806D1A2204B1D476E06@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D476E06@ESESSMB209.ericsson.se> 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=1413058596; bh=ew5VztbDVO+DJJ2nwUnzIGx3OFnHA96uSS6KnW7BSWA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=AUBz2sOvt8AS3dO/8GNGjjGmBr63UEHK8rjGtNLKw8+vt9KSvdUAgSZtKnXjfVhk5 pUIxR7K3r0ApU672b2pV5atGgNm04KYICCdCY+upf3XrR2HVcNUexOvIShNEGFYcbM KWNAis8pAGCiJD/kNKjFCKO9T3SyuenMvY3KZEcevt9RSPCSkO09W0hfQpfRcnT9/F aM7Du+M1gFE2i6KazUqMXKg9CYNtPZ5hOnemTdA/s/SWfziFg1JfOkpB4nD0/2rpvL +zfWSwj8eEJl1nvniCkW8aUVr5GrMRHcOc9+7DmIcOwn0MpCqK4Xzbsq2yXGg7gJxv /GQleZaw0Mk8Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zdQxELSy-jMM_y9iY_t-NYAQTY4 Subject: Re: [clue] CLUE Data Channel: Why mandate support of SCTP interleaving? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 20:16:39 -0000 On 10/11/14 1:23 PM, Christer Holmberg wrote: > Hi, > > I received a question on my the CLUE data channel spec mandates the > support of SCTP interleaving. In the core data channel spec support is a > SHOULD. > > As far as I remember, we didnt have any real discussion about it it > was just suggested and added to the draft :) I don't see any reason why we would need to strengthen the requirement from what is in the core data channel spec. Thanks, Paul From nobody Mon Oct 13 07:44:41 2014 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 EAC9A1A01AA for ; Mon, 13 Oct 2014 07:44:39 -0700 (PDT) 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 NQlIxdMzRGf3 for ; Mon, 13 Oct 2014 07:44:38 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839411A019B for ; Mon, 13 Oct 2014 07:44:38 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-08v.sys.comcast.net with comcast id 2ekN1p00756HXL001ekeWC; Mon, 13 Oct 2014 14:44:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id 2ekd1p00F3Ge9ey01ekdH6; Mon, 13 Oct 2014 14:44:37 +0000 Message-ID: <543BE555.9020801@alum.mit.edu> Date: Mon, 13 Oct 2014 10:44:37 -0400 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: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922CB4@CRPMBOXPRD08.polycom.com> <5429C727.7070407@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970EB@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970EB@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=1413211478; bh=sIMaJIez6AfS1Kyd39tkA2+i8pdJJm1nI8zdnGT2C/4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nUkNNqJl8HMAoc3unPB5rOeGTatsBTqsrLS7+fAIPS/f+3XUeqMywaHFXfqhGOLRJ 4hFA1c+daCaWJTNOV33oTn4UWiadYzuiJLc2FnB826SNFpBdx4ZtE4TeoInOpfsOZ0 XuhE14Sfc3lPiPIkIjCFANGAMtZZsyx6SgXiCS9eazFyS0hl/HnRLZwLy7hVOrqd1b HRqg5410mowKQKrAAi8y9eQA8+c+pcHRw5Ka2SWqXLkUR+QQ9BM2mhQnd1Kjbd+Ggg N6FbKiKKrj3wksqGDRhC4azO/XuubdPLEeusYUzYQbxCIkgyGm+cfqpg/hvpBpZGXV iwZ6mmJpRPU5Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5NAMhg2HUfISUvGpBQogRtpAiR8 Subject: Re: [clue] Updates in framework-17 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, 13 Oct 2014 14:44:40 -0000 On 10/10/14 6:20 PM, Duckworth, Mark wrote: > Thanks Paul. > comments inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, September 29, 2014 4:55 PM >> To: clue@ietf.org >> Subject: Re: [clue] Updates in framework-17 >> >> A few comments on the changes in this version: >> >> Section 3: >> >> Global View: A set of references to one or more Capture Scene Views >> of the same media type that are defined within scenes of the same >> advertisement. Each Global View in the list is a suggestion from >> the Provider to the Consumer for which CSVs provide a complete >> representation of the simultaneous captures provided by the >> Provider, across multiple scenes. >> >> This has munged two things into one. It is in part a definition of >> Global View and in part a definition of Global View List. I think both >> should be in the definitions. > [Duckworth, Mark] How about this: > > Global View: A set of references to one or more Capture Scene Views > of the same media type that are defined within scenes of the same > Advertisement. A Global View is a suggestion from > the Provider to the Consumer for which CSVs provide a complete > representation of the simultaneous captures provided by the > Provider, across multiple scenes. Fine. > Global View List: A list of Global Views included in an Advertisement. I think we need to clarify: does a Global View List contain only Global Views of a single media type? (This implies that we need a separate Global View List for each media type.) Or is there a single Global View List containing Global Views of different types? The data model currently has followed the second model. >> Media Consumer: a CLUE-capable device that that is capable of >> receiving Capture Encodings >> >> Media Provider: a CLUE-capable device that is capable of sending >> Capture Encodings >> >> I wonder if these defs should say "a CLUE-enabled* device. > > [Duckworth, Mark] We don't have a definition for "CLUE-enabled device". Would that be "a CLUE-capable device in a CLUE-enabled call"? ISTM the following are different states a *device* may be in: - is entirely clueless. It hasn't included the clue feature tag or the clue group. This is already defined as a Non-CLUE device. - it is aware of clue, but is unable or unwilling to use CLUE right now. It has included the clue feature tag, but not the clue group. Or else it has included the clue group but not included any SCTP m-line in the clue group. Perhaps this could be called CLUE-aware but CLUE-disabled. - it is aware of clue, and wishes to use it. It has included the clue feature tag, and the clue group, and has included an SCTP m-line in the clue group. Perhaps we can call this a CLUE-enabled device. (This doesn't mean the *call* is CLUE-enabled.) Note that this is distinct from the state of the call. You can have a clue-enabled *device* yet not have a clue-enabled *call* - both ends must be clue-enabled before the call is. >> Figure 1: >> >> While this shows the Global View List, it doesn't show any Global Views. >> Ideally it would - each referencing Scene Views. But it may be hard to >> fit all that into the single diagram. > > [Duckworth, Mark] I could make a separate diagram to show just Scenes, CSVs, Global Views, and a Global View List if you think that would be helpful. I think that would be good to have. What do others think? Thanks, Paul From nobody Mon Oct 13 09:07:59 2014 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 521361A1A9F for ; Mon, 13 Oct 2014 09:07:57 -0700 (PDT) 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 RX4tEu65pc-m for ; Mon, 13 Oct 2014 09:07:54 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF19B1A1A7A for ; Mon, 13 Oct 2014 09:07:54 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with comcast id 2g5o1p0075AAYLo01g7u2H; Mon, 13 Oct 2014 16:07:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id 2g7t1p00T3Ge9ey01g7tk8; Mon, 13 Oct 2014 16:07:54 +0000 Message-ID: <543BF8D9.20302@alum.mit.edu> Date: Mon, 13 Oct 2014 12:07:53 -0400 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: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> In-Reply-To: <543216B5.8080606@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=1413216474; bh=muQUWNxRxSKTx5OG9IiJRoc1TrVLrjNMtG9mUGfybi4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OtYZVniPr5PxmZ4h00xv0ZeZhxvMS6zmTPL1pzHCFfo0SWNWrLw5KlesKDWlffm4s 56mzRMaA5B4eGxyxBWjhfwXZWEh7YAbqBxv5bZgPKF7V0VhdXqi/VIi900TYDKSyUl rCdrqitAIQHXzzlHsE8sIQBU+lq4HKmISIG9HyuSiz8W4ofHoNfishNOtS864wxLui UwZ5LCXlAVzE45vwGs3eq4VMXKP0sK75YmyeNdNYEnkCsR1RXZVoq1DqFQP/ZJwjft m+q02+xZr2pVo3XQi8rh8Acy2Q+V6rm1vXxiRQbiTPlgFYCtNiEWJNhUOPrSvqkgcD 4Y+6Vw0q/M/Jg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qdlxjGgHSfDLHKhn57yjeIeKN6w Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Mon, 13 Oct 2014 16:07:57 -0000 On 10/6/14 12:12 AM, Christian Groves wrote: > Hello Roberta, > > Please see my replies below. > > Regards, Christian > > ..snip.. >> >>>> The optional field element "view" of type "viewType" is confusing >>>> since we switched to the sceneView and globalView terminology. I think >>>> we should come up with a new name for this. A couple of terms that >>>> come to mind are: "contentType" or "subjectType". >>>> >>> [RP] I propose instead of , and subjectType instead of >>> viewType. >> >> WFM > [CNG] I don't really agree with the use of "subject". When I read > "subject" I immediately think of what the conference is about. When I > read "view" I think of what I am seeing/hearing. I think the fact that > we use "sceneView" and "globalView" actually strengthens the reason we'd > use the term "view". To distinguish we could add capture i.e. > "captureView" "captureViewType". I will defer to the majority here. >>>> * Extensibility of enumerations: >>>> >>>> This came up on the call wrt sensitivityPatternType. But there are >>>> several enumerations that probably have the same concern: >>>> - personTypeType >>>> - viewType >>>> - presentationType >>>> - mobilityType >>>> - ? scaleType >>>> >>>> The usual ietf solution for extensibility is an IANA registry. That >>>> would be in lieu of enumerating them in the schema. If we went that >>>> way then the element would probably simply be of type string, and text >>>> would say that the valid values are defined in a registry, and that if >>>> a value is not understood it should be ignored. >>>> >>> [RP] >>> Thank you for listing them. >>> I'm not sure I understand correctly. >>> Are you saying that we should define such types as string an saying that >>> acceptable values are those registered with IANA? >>> Then, if we need to extend these types with new values, we need to >>> update the IANA registrations and nothing more. >>> Right? >> >> Yes. I'm offering that as one approach for handling the extensibility >> of these fields. But it seems a little odd in xml, so I'm certainly >> open to other approaches that are more natural for xml, if there are any. > [CNG] What i'd really like to see as part of the protocol document is an > appendix with a template of exactly what a new registration would look > like. I'd like to see that updates to CLUE can be made quickly without > 1+ year of specification effort. Rather than registering new values with > IANA, we can register the new "option" with IANA. e.g. in Megaco we > register the PackageID with IANA which effectively points to a template > for values/procedures. Putting them into IANA *might* make adding values easier. It depends on what registration procedure we choose. I am ok with making some things relatively each to add to. But not all. Some *ought* to have a high bar. For instance I wouldn't want to make it too easy to add a new viewType. If we made these IANA tables, how would that affect clue versioning? If anybody can add a value then doing so shouldn't affect the versioning. If we make the addition of a value Standards Action, then we could tie changes to a version number change. But we can decide that independently for each item. I'm not sure if it's "weird" to use iana registrations for xml enumerations - if there is some preferred way to do this for xml. Thanks, Paul From nobody Mon Oct 13 12:28:48 2014 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 F2B841A8F3C for ; Mon, 13 Oct 2014 12:28:46 -0700 (PDT) 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 Vy-wbnAheu2d for ; Mon, 13 Oct 2014 12:28:44 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1DB1A035D for ; Mon, 13 Oct 2014 12:28:43 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so6879458lbv.7 for ; Mon, 13 Oct 2014 12:28:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=toBsP0SQ526qUlpLH7VJBXdzwCgsCLXHajIdwNIsyso=; b=c5SH0MUyrK+trs8ogmSB74jKHguJBlACjUrjN+RNS6UA7ZUTrUnWKP2COSZ6HCs2zm VqCHRyj/bozfdFkwIj+EuOnnRHqE3D+8SNuQ51B6wuKZAawk7mzIngd0vGTxM5jXDIfR vUxMDZCaaDIGNt1ZO9J+3y9z50vYuSZoZyKzWuUNnbxEo5MNrAfRFotJuJ6kQ4lm03cW /nWEX1Nz2IOX3YCALpPP+aNFWmBt1mxMI+6UD49aOtzyizlrDopY49q7gnxYg7sXf3Dr T+Wv1jiBpFRYseexYzaTN1KfYVeUdjiZi6R1a4TYjXFxNwyaCokRWYJ1c/CMOBY0H2k2 /NJg== MIME-Version: 1.0 X-Received: by 10.112.173.134 with SMTP id bk6mr623687lbc.66.1413228522113; Mon, 13 Oct 2014 12:28:42 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Mon, 13 Oct 2014 12:28:42 -0700 (PDT) In-Reply-To: <543BF8D9.20302@alum.mit.edu> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> Date: Mon, 13 Oct 2014 14:28:42 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c23c8a0c0e9b050552e848 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-FIqvoq4wmoEjE0OfmnjGeNyWwY Cc: CLUE Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Mon, 13 Oct 2014 19:28:47 -0000 --001a11c23c8a0c0e9b050552e848 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Oct 13, 2014 at 11:07 AM, Paul Kyzivat wrote: > On 10/6/14 12:12 AM, Christian Groves wrote: > >> Hello Roberta, >> >> Please see my replies below. >> >> Regards, Christian >> >> ..snip.. >> >>> >>> The optional field element "view" of type "viewType" is confusing >>>>> since we switched to the sceneView and globalView terminology. I thin= k >>>>> we should come up with a new name for this. A couple of terms that >>>>> come to mind are: "contentType" or "subjectType". >>>>> >>>>> [RP] I propose instead of , and subjectType instead = of >>>> viewType. >>>> >>> >>> WFM >>> >> [CNG] I don't really agree with the use of "subject". When I read >> "subject" I immediately think of what the conference is about. When I >> read "view" I think of what I am seeing/hearing. I think the fact that >> we use "sceneView" and "globalView" actually strengthens the reason we'd >> use the term "view". To distinguish we could add capture i.e. >> "captureView" "captureViewType". >> > > I will defer to the majority here. > > > * Extensibility of enumerations: >>>>> >>>>> This came up on the call wrt sensitivityPatternType. But there are >>>>> several enumerations that probably have the same concern: >>>>> - personTypeType >>>>> - viewType >>>>> - presentationType >>>>> - mobilityType >>>>> - ? scaleType >>>>> >>>>> The usual ietf solution for extensibility is an IANA registry. That >>>>> would be in lieu of enumerating them in the schema. If we went that >>>>> way then the element would probably simply be of type string, and tex= t >>>>> would say that the valid values are defined in a registry, and that i= f >>>>> a value is not understood it should be ignored. >>>>> >>>>> [RP] >>>> Thank you for listing them. >>>> I'm not sure I understand correctly. >>>> Are you saying that we should define such types as string an saying th= at >>>> acceptable values are those registered with IANA? >>>> Then, if we need to extend these types with new values, we need to >>>> update the IANA registrations and nothing more. >>>> Right? >>>> >>> >>> Yes. I'm offering that as one approach for handling the extensibility >>> of these fields. But it seems a little odd in xml, so I'm certainly >>> open to other approaches that are more natural for xml, if there are an= y. >>> >> [CNG] What i'd really like to see as part of the protocol document is an >> appendix with a template of exactly what a new registration would look >> like. I'd like to see that updates to CLUE can be made quickly without >> 1+ year of specification effort. Rather than registering new values with >> IANA, we can register the new "option" with IANA. e.g. in Megaco we >> register the PackageID with IANA which effectively points to a template >> for values/procedures. >> > > Putting them into IANA *might* make adding values easier. It depends on > what registration procedure we choose. > > I am ok with making some things relatively each to add to. But not all. > Some *ought* to have a high bar. For instance I wouldn't want to make it > too easy to add a new viewType. > > If we made these IANA tables, how would that affect clue versioning? If > anybody can add a value then doing so shouldn't affect the versioning. If > we make the addition of a value Standards Action, then we could tie chang= es > to a version number change. But we can decide that independently for each > item. [MB] =10They should be registered as Standards Action required. [/MB] > > I'm not sure if it's "weird" to use iana registrations for xml > enumerations - if there is some preferred way to do this for xml. > [MB] This is not unusual. Take a look at RFC 6503. [/MB] > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a11c23c8a0c0e9b050552e848 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 13, 2014 at 11:07 AM, Paul Kyzivat <pkyzivat@alum.mit.= edu> wrote:
On 10/6/14 12:12 AM, Christian Groves wrote:
Hello Roberta,

Please see my replies below.

Regards, Christian

..snip..

The optional field element "view" of type "viewType" is= confusing
since we switched to the sceneView and globalView terminology. I think
we should come up with a new name for this. A couple of terms that
come to mind are: "contentType" or "subjectType".

[RP] I propose <subject> instead of <view>, and subjectType ins= tead of
viewType.

WFM
[CNG] I don't really agree with the use of "subject". When I = read
"subject" I immediately think of what the conference is about. Wh= en I
read "view" I think of what I am seeing/hearing. I think the fact= that
we use "sceneView" and "globalView" actually strengthen= s the reason we'd
use the term "view". To distinguish we could add capture i.e.
"captureView" "captureViewType".

 I will defer to the majority here.


* Extensibility of enumerations:

This came up on the call wrt sensitivityPatternType. But there are
several enumerations that probably have the same concern:
- personTypeType
- viewType
- presentationType
- mobilityType
- ? scaleType

The usual ietf solution for extensibility is an IANA registry. That
would be in lieu of enumerating them in the schema. If we went that
way then the element would probably simply be of type string, and text
would say that the valid values are defined in a registry, and that if
a value is not understood it should be ignored.

[RP]
Thank you for listing them.
I'm not sure I understand correctly.
Are you saying that we should define such types as string an saying that acceptable values are those registered with IANA?
Then, if we need to extend these types with new values, we need to
update the IANA registrations and nothing more.
Right?

Yes. I'm offering that as one approach for handling the extensibility of these fields. But it seems a little odd in xml, so I'm certainly
open to other approaches that are more natural for xml, if there are any.
[CNG] What i'd really like to see as part of the protocol document is a= n
appendix with a template of exactly what a new registration would look
like. I'd like to see that updates to CLUE can be made quickly without<= br> 1+ year of specification effort. Rather than registering new values with IANA, we can register the new "option" with IANA. e.g. in Megaco = we
register the PackageID with IANA which effectively points to a template
for values/procedures.

Putting them into IANA *might* make adding values easier. It depends on wha= t registration procedure we choose.

I am ok with making some things relatively each to add to. But not all. Som= e *ought* to have a high bar. For instance I wouldn't want to make it t= oo easy to add a new viewType.

If we made these IANA tables, how would that affect clue versioning? If any= body can add a value then doing so shouldn't affect the versioning. If = we make the addition of a value Standards Action, then we could tie changes= to a version number change. But we can decide that independently for each = item.=C2=A0
[MB] =10They should be registered as Standards= Action required. [/MB]=C2=A0

I'm not sure if it's "weird" to use iana registrations fo= r xml enumerations - if there is some preferred way to do this for xml.
=
[MB] This is not unusual.=C2=A0 Take a look at RFC 6503. = [/MB]=C2=A0

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

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

--001a11c23c8a0c0e9b050552e848-- From nobody Mon Oct 13 12:39:58 2014 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 3CEF11A6FE9 for ; Mon, 13 Oct 2014 12:39:57 -0700 (PDT) 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 E6nWxRY-46-E for ; Mon, 13 Oct 2014 12:39:55 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20A61A6FFA for ; Mon, 13 Oct 2014 12:39:54 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so7086335lbd.34 for ; Mon, 13 Oct 2014 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6hjGoo4jhlaNFFw5L+zoSN/MRT6Qm4xg6cjDVZSjhJ0=; b=Pgbo3AaQcEVH/pu3/ZUhu49nvWpkKvmAKVGeLMTJmy/WzHQ+uLj0djW+RZ0bB2sH+3 JX83IEl661nNAr0DkuMuB6EDQzjL51YbT9vmsDb7QAZuvAucz0YZIOpPRSwTa+a898MX 8eDWCBq7hLTkbxyn3K0T8hRS3IVPNOhcBpA5qxZicZoZEk3vC/XY+FMIltOOf2QIcLhp 4lMMjdVXIWcRo21KxQkqCVkoFzXWoEFD7Wr+RH+Rjd9rCDJieDcMmFTKAFBkmljIrpEn Z9QXfINZSjMQuRxLrrIoWd7wMp3Rj9M4M4Ki1nU3x6R4rfzhiFfh5SgCHPEPSlaXbnOQ TutA== MIME-Version: 1.0 X-Received: by 10.152.36.230 with SMTP id t6mr648151laj.88.1413229193278; Mon, 13 Oct 2014 12:39:53 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Mon, 13 Oct 2014 12:39:53 -0700 (PDT) In-Reply-To: <543355B5.6040306@nteczone.com> References: <543355B5.6040306@nteczone.com> Date: Mon, 13 Oct 2014 14:39:53 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e0160c0dc0d3b5c0505531059 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/prORfbjKRcfAMxV35ayx_1ZpcEk Cc: "clue@ietf.org" Subject: Re: [clue] Design team meeting on protocols 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, 13 Oct 2014 19:39:57 -0000 --089e0160c0dc0d3b5c0505531059 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 6, 2014 at 9:53 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > I won't be able to attend the design team meeting. The recent daylight > saving time change means it's too late for my part of the world. > > A couple of comments that might be relevant to discussions: > 1) I still have an issue with the use of READV ACK for returning CLUE > Info. The main issue is how to return an error if there's a fault in the > CLUEinfo? e.g. for an Advertisement the MC can send a NACK indicating an > error. I think its simply cleaner to always use an Advertisement to provide > CLUE info. > > 2) With regards to the open ticket on partial updates, I provided > draft-groves-clue-partial-update-00 to address this by presenting how > partial updates could be done. I haven't received any feedback on this. > [MB] We didn't discuss this on the call due to time constraints. As chair, I take the lack of comments to mean that people are currently not interested in solving this problem. If people feel otherwise, please respond no later than October 20th, so we can decide how to move forward. Christian - are you planning on being at IETF-91? If not, then it would be quite challenging to completely resolve this in a timely manner. We are behind schedule and it would be really good to finish the core specifications and then look at this problem if there is consensus that people want to handle this issue. [/MB] > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e0160c0dc0d3b5c0505531059 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Oct 6, 2014 at 9:53 PM, Christian Groves <= Christia= n.Groves@nteczone.com> wrote:
Hello,

I won't be able to attend the design team meeting. The recent daylight = saving time change means it's too late for my part of the world.

A couple of comments that might be relevant to discussions:
1) I still have an issue with the use of READV ACK for returning CLUE Info.= The main issue is how to return an error if there's a fault in the CLU= Einfo? e.g. for an Advertisement the MC can send a NACK indicating an error= . I think its simply cleaner to always use an Advertisement to provide CLUE= info.

2) With regards to the open ticket on partial updates, I provided draft-gro= ves-clue-partial-update-00 to address this by presenting how partial= updates could be done. I haven't received any feedback on this.
[MB] We didn't discuss this on the call due to time cons= traints. As chair, I take the lack of comments to mean that people are curr= ently not interested in solving this problem.=C2=A0 If people feel otherwis= e, please respond no later than October 20th, so we can decide how to move = forward.=C2=A0 Christian - are you planning on being at IETF-91?=C2=A0 If n= ot, then it would be quite challenging to completely resolve this in a time= ly manner.=C2=A0 We are behind schedule and it would be really good to fini= sh the core specifications and then look at this problem if there is consen= sus that people want to handle this issue.=C2=A0
[/MB]

Regards, Christian

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

--089e0160c0dc0d3b5c0505531059-- From nobody Mon Oct 13 16:21:19 2014 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 80CFC1A1A6D for ; Mon, 13 Oct 2014 16:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCmxsDPhgwIZ for ; Mon, 13 Oct 2014 16:21:14 -0700 (PDT) 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 A3C071A1A56 for ; Mon, 13 Oct 2014 16:21:04 -0700 (PDT) Received: from ppp118-209-161-20.lns20.mel8.internode.on.net ([118.209.161.20]:52905 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xdou6-0005Mz-HH for clue@ietf.org; Tue, 14 Oct 2014 10:19:50 +1100 Message-ID: <543C5E5C.60309@nteczone.com> Date: Tue, 14 Oct 2014 10:21:00 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922CB4@CRPMBOXPRD08.polycom.com> <5429C727.7070407@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970EB@CRPMBOXPRD08.polycom.com> <543BE555.9020801@alum.mit.edu> In-Reply-To: <543BE555.9020801@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DtC3fNjuOBcQDJLXMpRxEr-GJlg Subject: Re: [clue] Updates in framework-17 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, 13 Oct 2014 23:21:16 -0000 Hello > >> Global View List: A list of Global Views included in an Advertisement. > > I think we need to clarify: does a Global View List contain only > Global Views of a single media type? (This implies that we need a > separate Global View List for each media type.) Or is there a single > Global View List containing Global Views of different types? The data > model currently has followed the second model. [CNG] Scenes contains different types of media (e.g. audio and video) so would then a list of scenes (Global View List) then also refers to different types of media? ..snip.. >>> Figure 1: >>> >>> While this shows the Global View List, it doesn't show any Global >>> Views. >>> Ideally it would - each referencing Scene Views. But it may be hard to >>> fit all that into the single diagram. >> >> [Duckworth, Mark] I could make a separate diagram to show just >> Scenes, CSVs, Global Views, and a Global View List if you think that >> would be helpful. > > I think that would be good to have. What do others think? [CNG] I think it would be beneficial. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Oct 13 16:38:32 2014 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 B252C1A1A59 for ; Mon, 13 Oct 2014 16:38:28 -0700 (PDT) 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 GN502wILMxOj for ; Mon, 13 Oct 2014 16:38:27 -0700 (PDT) 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 B91181A1A52 for ; Mon, 13 Oct 2014 16:38:26 -0700 (PDT) Received: from ppp118-209-161-20.lns20.mel8.internode.on.net ([118.209.161.20]:53122 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XdpAu-00085a-A9; Tue, 14 Oct 2014 10:37:12 +1100 Message-ID: <543C626D.3060806@nteczone.com> Date: Tue, 14 Oct 2014 10:38:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mary Barnes References: <543355B5.6040306@nteczone.com> In-Reply-To: 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/aFsU33_KlnC_BQybMHsFEDsgShc Cc: "clue@ietf.org" Subject: Re: [clue] Design team meeting on protocols 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, 13 Oct 2014 23:38:28 -0000 Hello Mary, On 14/10/2014 6:39 AM, Mary Barnes wrote: > > > On Mon, Oct 6, 2014 at 9:53 PM, Christian Groves > > > wrote: > > Hello, > > I won't be able to attend the design team meeting. The recent > daylight saving time change means it's too late for my part of the > world. > > A couple of comments that might be relevant to discussions: > 1) I still have an issue with the use of READV ACK for returning > CLUE Info. The main issue is how to return an error if there's a > fault in the CLUEinfo? e.g. for an Advertisement the MC can send a > NACK indicating an error. I think its simply cleaner to always use > an Advertisement to provide CLUE info. > > 2) With regards to the open ticket on partial updates, I provided > draft-groves-clue-partial-update-00 to address this by presenting > how partial updates could be done. I haven't received any feedback > on this. > > [MB] We didn't discuss this on the call due to time constraints. As > chair, I take the lack of comments to mean that people are currently > not interested in solving this problem. If people feel otherwise, > please respond no later than October 20th, so we can decide how to > move forward. Christian - are you planning on being at IETF-91? If > not, then it would be quite challenging to completely resolve this in > a timely manner. We are behind schedule and it would be really good > to finish the core specifications and then look at this problem if > there is consensus that people want to handle this issue. > [/MB] [CNG] Unfortunately I won't be at the upcoming IETF. The reason I submitted the draft was to try to progress the open issues on the protocol document, of which partial updates was one. The intention was to indicate what would be required for the partial update mechanism so that we could make an educated decision on whether or not to include the mechanism rather than just closing the item because there was no input. The approach and mechanism isn't really new as its been used to modify other XML based protocols so it shouldn't be controversial. From the meeting notes (http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-141007.txt): * Ticket #25 – deltas for ADV? 71 Will include the groves partial update mechanism in next version 72 73 Will make use of deltas a MAY. It sounded like it would be added? I'm OK if we decide not to include it in the core protocol spec at the moment. However we should ensure that the protocol extension mechanisms would support the inclusion of the partial update mechanism at a later time. Was the READV issue discussed? Regards, Christian > > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Oct 13 17:04:07 2014 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 8DFAD1A1A5A for ; Mon, 13 Oct 2014 17:04:05 -0700 (PDT) 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 OfVEq_73O-_5 for ; Mon, 13 Oct 2014 17:04:03 -0700 (PDT) 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 D7EBA1A1A4C for ; Mon, 13 Oct 2014 17:04:02 -0700 (PDT) Received: from ppp118-209-161-20.lns20.mel8.internode.on.net ([118.209.161.20]:53367 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XdpZh-0003LX-2D for clue@ietf.org; Tue, 14 Oct 2014 11:02:49 +1100 Message-ID: <543C686F.8010907@nteczone.com> Date: Tue, 14 Oct 2014 11:03:59 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rIBdie5YU9SKntu59ujAMPNzcSc Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Tue, 14 Oct 2014 00:04:05 -0000 Hello Mary and Paul, > > > * Extensibility of enumerations: > > This came up on the call wrt > sensitivityPatternType. But there are > several enumerations that probably have the same > concern: > - personTypeType > - viewType > - presentationType > - mobilityType > - ? scaleType > > The usual ietf solution for extensibility is an > IANA registry. That > would be in lieu of enumerating them in the > schema. If we went that > way then the element would probably simply be of > type string, and text > would say that the valid values are defined in a > registry, and that if > a value is not understood it should be ignored. > > [RP] > Thank you for listing them. > I'm not sure I understand correctly. > Are you saying that we should define such types as > string an saying that > acceptable values are those registered with IANA? > Then, if we need to extend these types with new > values, we need to > update the IANA registrations and nothing more. > Right? > > > Yes. I'm offering that as one approach for handling the > extensibility > of these fields. But it seems a little odd in xml, so I'm > certainly > open to other approaches that are more natural for xml, if > there are any. > > [CNG] What i'd really like to see as part of the protocol > document is an > appendix with a template of exactly what a new registration > would look > like. I'd like to see that updates to CLUE can be made quickly > without > 1+ year of specification effort. Rather than registering new > values with > IANA, we can register the new "option" with IANA. e.g. in > Megaco we > register the PackageID with IANA which effectively points to a > template > for values/procedures. > > > Putting them into IANA *might* make adding values easier. It > depends on what registration procedure we choose. > > I am ok with making some things relatively each to add to. But not > all. Some *ought* to have a high bar. For instance I wouldn't want > to make it too easy to add a new viewType. > [CNG] I agree some should have a higher bar. I wouldn't have thought viewType was one. What is it about viewType that you feel should have a high bar. > > > If we made these IANA tables, how would that affect clue > versioning? If anybody can add a value then doing so shouldn't > affect the versioning. If we make the addition of a value > Standards Action, then we could tie changes to a version number > change. But we can decide that independently for each item. > > [MB] They should be registered as Standards Action required. [/MB] [CNG] Actually I think we want to avoid "standards action" for adding values/attributes. I think that "expert review" or "specification required" would be sufficient. I think that needing a standards action for every small update will stifle the potential uses of CLUE. We don't know all the application scenarios where CLUE will be used and there may be application scenario specific metadata that could be sent via CLUE. It should be easy to add this without a long drawn out IETF standards action process. Does the IESG want to be bothered with having to review/process/meet to add value to an existing attribute? I agree that adding new core CLUE syntax, messages etc should be standards action required. With regards to versioning I think any core protocol updates would be handled by version number changes. Any additional attributes/values other than those defined in the core protocol document would be handled via the OPTIONS message. So if we take the framework document my proposal would be that any change to the existing protocol would require a "Standards Action" except for: 7.1.1. Media Capture Attributes 7.2.1. MCC Attributes 7.3.1. Capture Scene attributes 7.3.2. Capture Scene View attributes. 9.2 Encoding Group attributes where new values or new attributes could be added via expert review/specification required. The use of these new attributes/values would be signalled via an OPTIONS message. > > I'm not sure if it's "weird" to use iana registrations for xml > enumerations - if there is some preferred way to do this for xml. > > [MB] This is not unusual. Take a look at RFC 6503. [/MB] > > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Oct 14 08:28:08 2014 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 E5B521A88E5 for ; Tue, 14 Oct 2014 08:27:53 -0700 (PDT) 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 V8i_ICMuu2qh for ; Tue, 14 Oct 2014 08:27:52 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1BF1A8944 for ; Tue, 14 Oct 2014 08:27:52 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with comcast id 33RF1p00352QWKC013Tst2; Tue, 14 Oct 2014 15:27:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id 33Tr1p00D3Ge9ey013TrN3; Tue, 14 Oct 2014 15:27:52 +0000 Message-ID: <543D40F7.4090708@alum.mit.edu> Date: Tue, 14 Oct 2014 11:27:51 -0400 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: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5A922CB4@CRPMBOXPRD08.polycom.com> <5429C727.7070407@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA970EB@CRPMBOXPRD08.polycom.com> <543BE555.9020801@alum.mit.edu> <543C5E5C.60309@nteczone.com> In-Reply-To: <543C5E5C.60309@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=1413300472; bh=ht+1Z+mKtyt6xWUBDDg9kmrbi5VwdWQN1H33o3Zb3dw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jZxkGIhKYVyAihiIyDH6uFVlrhsKWPeXekfUIRM52j56HOqEnYaCWW+Vsd0M0Zmk8 vRrSJZTYnCvI7Zg6ao7KwtZgEMWOjSOH83J5zdI80j2z+5sma3XJBbV3lwJd3tFjhZ WNHYPRL9dkl1aMqilXgNqBZ6uE8xVX4iL+0d4smJzZn/WOw63WEHhTk2xCXEApERZi x7pNqSP03kbNLbppGIBSve4IKog5xJa+2Nhnt4Zc6/i9TUJtAdeG1bBWMVKTRC5G68 RRJS+XfRqu1ifXivJbTh1gmgqrAv8cjN94ZaFwow99VBKob5rE611+oTC6zHO0VeTj 6RtZY7PUElATQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/37LodixYe_1D_Vf_D8FD83YIcRg Subject: Re: [clue] Updates in framework-17 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, 14 Oct 2014 15:27:56 -0000 On 10/13/14 7:21 PM, Christian Groves wrote: > Hello > >> >>> Global View List: A list of Global Views included in an Advertisement. >> >> I think we need to clarify: does a Global View List contain only >> Global Views of a single media type? (This implies that we need a >> separate Global View List for each media type.) Or is there a single >> Global View List containing Global Views of different types? The data >> model currently has followed the second model. > [CNG] Scenes contains different types of media (e.g. audio and video) so > would then a list of scenes (Global View List) then also refers to > different types of media? - Each scene contains a number of captures, each of a particular media type. - Each scene contains a single sceneViews element. That contains a number of sceneView elements. This includes sceneView elements of differing media types. - Each sceneView element contains a mediaCaptureIDs element referencing a number of mediaCapture elements in the scene and all of a single media type. - The advertisement contains a *single* globalViews element, that contains multiple globalView elements. (Hence it had better encompass multiple media types.) - The globalView element references multiple sceneView elements. There is currently no statement whether or not all the sceneView elements referenced by a globalView must be of the same type. We must make a choice here: 1) for a particular globalView element, all of the referenced sceneView elements must be of a single media type. In this case, a consumer should choose one globalView element of each type. 2) each globalView element may reference sceneView elements of multiple media types. Presumably in this case the chosen sceneView elements of differing types have been chosen to work well together. Presumably a consumer should choose a single globalView element. We already made a similar choice when we decided to restrict the elements of a sceneView to a single type. If we want to be consistent with that, then we should choose (1) above. The tradeoffs are: For (1): - the assumption is that the choice of views for different media types are independent - any audio will work equally well with any video. This may not be true. For (2): - this is (arguably) easier for the consumer. It need only search for a single globalView that it can render. And when it chooses one, it can assume that it is a well tuned combination of the different media types. - if media of different types *are* independent, then it will take more globalView elements to describe all the combinations than (1) does. Thanks, Paul From nobody Tue Oct 14 12:19:14 2014 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 ECA3E1ACE8A for ; Tue, 14 Oct 2014 12:19:10 -0700 (PDT) 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 E391MPGsStC5 for ; Tue, 14 Oct 2014 12:19:09 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B791ACE7C for ; Tue, 14 Oct 2014 12:17:46 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-11v.sys.comcast.net with comcast id 37Ha1p0055FMDhs017Hm6Q; Tue, 14 Oct 2014 19:17:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id 37Hl1p00a3Ge9ey017HmKj; Tue, 14 Oct 2014 19:17:46 +0000 Message-ID: <543D76D9.3080506@alum.mit.edu> Date: Tue, 14 Oct 2014 15:17:45 -0400 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: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> In-Reply-To: <543C686F.8010907@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=1413314266; bh=gz+iPzATop546MAANWOynSMhyrsSY6kmRpxWjAijeYc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PiWBrbB00X3QdzfTmfT4c/VH5kCUalT7q0XWrmuto/nkX9vobPPwVX64qjMRJT8/8 mHblhLu/MJvI/mHLaMfE+vP0yQ12KIe6E4VULspjpZxdY4whblSumN2DJZag9adfCk Q1kdQBJBe3jyTiY4BhyKBhNQXd5WHUQNvl9D34HphAg/Aa6Sn93n+N8J3R3m3xk8sJ TF0c4OdvXdwaaUnBeZx4mAqGF2ymmVKIFx7xxOhMBuUdgEYvzf5BJ8ticJZKEqZJpe z6OfA1YYXln4TLLd5dHW/3cAMv5ninHZcs8Ahk2HcOSAvDoDEDnBurkStiZaESY+cM 4ZFhgEJIoo+kw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SF4UmG2P0jspxr7PubqdbELUuZA Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Tue, 14 Oct 2014 19:19:11 -0000 On 10/13/14 8:03 PM, Christian Groves wrote: > Hello Mary and Paul, > >> >> >> * Extensibility of enumerations: >> >> This came up on the call wrt >> sensitivityPatternType. But there are >> several enumerations that probably have the same >> concern: >> - personTypeType >> - viewType >> - presentationType >> - mobilityType >> - ? scaleType >> >> The usual ietf solution for extensibility is an >> IANA registry. That >> would be in lieu of enumerating them in the >> schema. If we went that >> way then the element would probably simply be of >> type string, and text >> would say that the valid values are defined in a >> registry, and that if >> a value is not understood it should be ignored. >> >> [RP] >> Thank you for listing them. >> I'm not sure I understand correctly. >> Are you saying that we should define such types as >> string an saying that >> acceptable values are those registered with IANA? >> Then, if we need to extend these types with new >> values, we need to >> update the IANA registrations and nothing more. >> Right? >> >> >> Yes. I'm offering that as one approach for handling the >> extensibility >> of these fields. But it seems a little odd in xml, so I'm >> certainly >> open to other approaches that are more natural for xml, if >> there are any. >> >> [CNG] What i'd really like to see as part of the protocol >> document is an >> appendix with a template of exactly what a new registration >> would look >> like. I'd like to see that updates to CLUE can be made quickly >> without >> 1+ year of specification effort. Rather than registering new >> values with >> IANA, we can register the new "option" with IANA. e.g. in >> Megaco we >> register the PackageID with IANA which effectively points to a >> template >> for values/procedures. >> >> >> Putting them into IANA *might* make adding values easier. It >> depends on what registration procedure we choose. >> >> I am ok with making some things relatively each to add to. But not >> all. Some *ought* to have a high bar. For instance I wouldn't want >> to make it too easy to add a new viewType. >> > [CNG] I agree some should have a higher bar. I wouldn't have thought > viewType was one. What is it about viewType that you feel should have a > high bar. I didn't (though maybe Mary did). I was speaking in general about whatever we put into IANA registries - we need to decide case by case how high the bar should be. The specific items under discussion here are: - personTypeType - viewType - presentationType - mobilityType - ? scaleType Note that I put a question mark by scaleType. I think that one deserves a high bar and to require version or option negotiation. For the others, I would be comfortable with expert review. And I would not expect new clue version/option for it - just ignore unknown values. Thanks, Paul >> If we made these IANA tables, how would that affect clue >> versioning? If anybody can add a value then doing so shouldn't >> affect the versioning. If we make the addition of a value >> Standards Action, then we could tie changes to a version number >> change. But we can decide that independently for each item. >> [MB] They should be registered as Standards Action required. [/MB] > [CNG] Actually I think we want to avoid "standards action" for adding > values/attributes. I think that "expert review" or "specification > required" would be sufficient. I think that needing a standards action > for every small update will stifle the potential uses of CLUE. We don't > know all the application scenarios where CLUE will be used and there may > be application scenario specific metadata that could be sent via CLUE. > It should be easy to add this without a long drawn out IETF standards > action process. Does the IESG want to be bothered with having to > review/process/meet to add value to an existing attribute? > > I agree that adding new core CLUE syntax, messages etc should be > standards action required. > > With regards to versioning I think any core protocol updates would be > handled by version number changes. Any additional attributes/values > other than those defined in the core protocol document would be handled > via the OPTIONS message. > > So if we take the framework document my proposal would be that any > change to the existing protocol would require a "Standards Action" > except for: > 7.1.1. Media Capture Attributes > 7.2.1. MCC Attributes > 7.3.1. Capture Scene attributes > 7.3.2. Capture Scene View attributes. > 9.2 Encoding Group attributes > where new values or new attributes could be added via expert > review/specification required. The use of these new attributes/values > would be signalled via an OPTIONS message. > > >> >> I'm not sure if it's "weird" to use iana registrations for xml >> enumerations - if there is some preferred way to do this for xml. >> >> [MB] This is not unusual. Take a look at RFC 6503. [/MB] >> >> >> Thanks, >> Paul >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Oct 14 12:58:38 2014 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 7446E1ACF08 for ; Tue, 14 Oct 2014 12:58:37 -0700 (PDT) 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 Ooht_D5gOFbx for ; Tue, 14 Oct 2014 12:58:34 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D927F1ACEB9 for ; Tue, 14 Oct 2014 12:58:33 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so8920447lbi.36 for ; Tue, 14 Oct 2014 12:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y+4VW8EniUMK46qqYwFoVGRudR/YbCYTUh4L2iwhz54=; b=EE9oAu48uypHaznTWfr/ZE8GnaVMs0XrxzrKPVk3FkH3ndkQK4i/NeeDX9e7IIZrR/ fUmA4+v6P/aRIFk+GWWaQL7pnmhFFFNhYg6zm7BIjPSf9sXgXrXU5/ZCSwH1cvGEKalU kJjZdygGN9ljo3MLQ/MCHY2gZucMe1d38ofON1ZmDDnwG19VlcMWGvHLEns2uNjGLh7g QT9dCiwPBAbK/NO6dIZ0GSFibdHcAJFS6Lli5XYkImlVf2H1NtiS4TYyZsummJJEmxYg U6UaJm+jUzWESTFf+DAIXYXxeP+vV5g30T/JNoGMSBwbVQDpl/K7+bycvihHiYViAfq+ Cunw== MIME-Version: 1.0 X-Received: by 10.152.1.42 with SMTP id 10mr7935515laj.4.1413316712094; Tue, 14 Oct 2014 12:58:32 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Tue, 14 Oct 2014 12:58:32 -0700 (PDT) In-Reply-To: <543D76D9.3080506@alum.mit.edu> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> Date: Tue, 14 Oct 2014 14:58:32 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e013c65bc94600e0505677044 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/S3APUdU6IVgrrsmb7TY34O6ISjc Cc: CLUE Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Tue, 14 Oct 2014 19:58:37 -0000 --089e013c65bc94600e0505677044 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 14, 2014 at 2:17 PM, Paul Kyzivat wrote: > On 10/13/14 8:03 PM, Christian Groves wrote: > >> Hello Mary and Paul, >> >> >>> >>> * Extensibility of enumerations: >>> >>> This came up on the call wrt >>> sensitivityPatternType. But there are >>> several enumerations that probably have the same >>> concern: >>> - personTypeType >>> - viewType >>> - presentationType >>> - mobilityType >>> - ? scaleType >>> >>> The usual ietf solution for extensibility is an >>> IANA registry. That >>> would be in lieu of enumerating them in the >>> schema. If we went that >>> way then the element would probably simply be of >>> type string, and text >>> would say that the valid values are defined in a >>> registry, and that if >>> a value is not understood it should be ignored. >>> >>> [RP] >>> Thank you for listing them. >>> I'm not sure I understand correctly. >>> Are you saying that we should define such types as >>> string an saying that >>> acceptable values are those registered with IANA? >>> Then, if we need to extend these types with new >>> values, we need to >>> update the IANA registrations and nothing more. >>> Right? >>> >>> >>> Yes. I'm offering that as one approach for handling the >>> extensibility >>> of these fields. But it seems a little odd in xml, so I'm >>> certainly >>> open to other approaches that are more natural for xml, if >>> there are any. >>> >>> [CNG] What i'd really like to see as part of the protocol >>> document is an >>> appendix with a template of exactly what a new registration >>> would look >>> like. I'd like to see that updates to CLUE can be made quickly >>> without >>> 1+ year of specification effort. Rather than registering new >>> values with >>> IANA, we can register the new "option" with IANA. e.g. in >>> Megaco we >>> register the PackageID with IANA which effectively points to a >>> template >>> for values/procedures. >>> >>> >>> Putting them into IANA *might* make adding values easier. It >>> depends on what registration procedure we choose. >>> >>> I am ok with making some things relatively each to add to. But not >>> all. Some *ought* to have a high bar. For instance I wouldn't want >>> to make it too easy to add a new viewType. >>> >>> [CNG] I agree some should have a higher bar. I wouldn't have thought >> viewType was one. What is it about viewType that you feel should have a >> high bar. >> > > I didn't (though maybe Mary did). I was speaking in general about whatever > we put into IANA registries - we need to decide case by case how high the > bar should be. > [MB] Nope. I was not speaking to view type. I's really hard to follow attributions when people don't preface with initials or whatever and expect an email program's rules to be sufficient. Certainly, expert review with specification required could be an option. I would be very wary of having a registry without such. I'm not seeing in not having these things documented somewhere if we think we need an IANA registry as is. [/MB] > > The specific items under discussion here are: > > - personTypeType > - viewType > - presentationType > - mobilityType > - ? scaleType > > Note that I put a question mark by scaleType. I think that one deserves a > high bar and to require version or option negotiation. > > For the others, I would be comfortable with expert review. And I would not > expect new clue version/option for it - just ignore unknown values. > > Thanks, > Paul > > > If we made these IANA tables, how would that affect clue >>> versioning? If anybody can add a value then doing so shouldn't >>> affect the versioning. If we make the addition of a value >>> Standards Action, then we could tie changes to a version number >>> change. But we can decide that independently for each item. >>> [MB] They should be registered as Standards Action required. [/MB] >>> >> [CNG] Actually I think we want to avoid "standards action" for adding >> values/attributes. I think that "expert review" or "specification >> required" would be sufficient. I think that needing a standards action >> for every small update will stifle the potential uses of CLUE. We don't >> know all the application scenarios where CLUE will be used and there may >> be application scenario specific metadata that could be sent via CLUE. >> It should be easy to add this without a long drawn out IETF standards >> action process. Does the IESG want to be bothered with having to >> review/process/meet to add value to an existing attribute? >> >> I agree that adding new core CLUE syntax, messages etc should be >> standards action required. >> >> With regards to versioning I think any core protocol updates would be >> handled by version number changes. Any additional attributes/values >> other than those defined in the core protocol document would be handled >> via the OPTIONS message. >> >> So if we take the framework document my proposal would be that any >> change to the existing protocol would require a "Standards Action" >> except for: >> 7.1.1. Media Capture Attributes >> 7.2.1. MCC Attributes >> 7.3.1. Capture Scene attributes >> 7.3.2. Capture Scene View attributes. >> 9.2 Encoding Group attributes >> where new values or new attributes could be added via expert >> review/specification required. The use of these new attributes/values >> would be signalled via an OPTIONS message. >> >> >> >>> I'm not sure if it's "weird" to use iana registrations for xml >>> enumerations - if there is some preferred way to do this for xml. >>> >>> [MB] This is not unusual. Take a look at RFC 6503. [/MB] >>> >>> >>> Thanks, >>> Paul >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e013c65bc94600e0505677044 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 14, 2014 at 2:17 PM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
On 10/= 13/14 8:03 PM, Christian Groves wrote:
Hello Mary and Paul,



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 * Ext= ensibility of enumerations:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = came up on the call wrt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sensi= tivityPatternType. But there are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sever= al enumerations that probably have the same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conce= rn:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - per= sonTypeType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - vie= wType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - pre= sentationType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - mob= ilityType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ? s= caleType

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The u= sual ietf solution for extensibility is an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA = registry. That
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would= be in lieu of enumerating them in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 schem= a. If we went that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 way t= hen the element would probably simply be of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type = string, and text
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 would= say that the valid values are defined in a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 regis= try, and that if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a val= ue is not understood it should be ignored.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [RP]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you for listi= ng them.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I'm not sure I = understand correctly.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Are you saying that= we should define such types as
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string an saying th= at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 acceptable values a= re those registered with IANA?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Then, if we need to= extend these types with new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 values, we need to<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 update the IANA reg= istrations and nothing more.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Right?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes. I'm offering that as one= approach for handling the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 extensibility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of these fields. But it seems a l= ittle odd in xml, so I'm
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 certainly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 open to other approaches that are= more natural for xml, if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 there are any.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [CNG] What i'd really like to see as part o= f the protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 document is an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 appendix with a template of exactly what a new = registration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would look
=C2=A0 =C2=A0 =C2=A0 =C2=A0 like. I'd like to see that updates to CLUE = can be made quickly
=C2=A0 =C2=A0 =C2=A0 =C2=A0 without
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1+ year of specification effort. Rather than re= gistering new
=C2=A0 =C2=A0 =C2=A0 =C2=A0 values with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 IANA, we can register the new "option"= ; with IANA. e.g. in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Megaco we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 register the PackageID with IANA which effectiv= ely points to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 template
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for values/procedures.


=C2=A0 =C2=A0 Putting them into IANA *might* make adding values easier. It<= br> =C2=A0 =C2=A0 depends on what registration procedure we choose.

=C2=A0 =C2=A0 I am ok with making some things relatively each to add to. Bu= t not
=C2=A0 =C2=A0 all. Some *ought* to have a high bar. For instance I wouldn&#= 39;t want
=C2=A0 =C2=A0 to make it too easy to add a new viewType.

[CNG] I agree some should have a higher bar. I wouldn't have thought viewType was one. What is it about viewType that you feel should have a
high bar.

I didn't (though maybe Mary did). I was speaking in general about whate= ver we put into IANA registries - we need to decide case by case how high t= he bar should be.
[MB] Nope. I was not =C2=A0speaking = to view type.=C2=A0 I's really hard to follow attributions when people = don't preface with initials or whatever and expect an email program'= ;s rules to be sufficient.=C2=A0 Certainly, expert review with specificatio= n required could be an option.=C2=A0 I would be very wary of having a regis= try without such. I'm not seeing in not having these things documented = somewhere if we think we need an IANA registry as is. [/MB]=C2=A0

The specific items under discussion here are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - per= sonTypeType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - vie= wType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - pre= sentationType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - mob= ilityType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 - ? s= caleType

 Note that I put a question mark by scaleType. I think that one deserves a h= igh bar and to require version or option negotiation.

For the others, I would be comfortable with expert review. And I would not = expect new clue version/option for it - just ignore unknown values.

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


=C2=A0 =C2=A0 If we made these IANA tables, how would that affect clue
=C2=A0 =C2=A0 versioning? If anybody can add a value then doing so shouldn&= #39;t
=C2=A0 =C2=A0 affect the versioning. If we make the addition of a value
=C2=A0 =C2=A0 Standards Action, then we could tie changes to a version numb= er
=C2=A0 =C2=A0 change. But we can decide that independently for each item. [MB]=C2=A0 They should be registered as Standards Action required. [/MB]
[CNG] Actually I think we want to avoid "standards action" for ad= ding
values/attributes. I think that "expert review" or "specific= ation
required" would be sufficient. I think that needing a standards action=
for every small update will stifle the potential uses of CLUE. We don't=
know all the application scenarios where CLUE will be used and there may be application scenario specific metadata that could be sent via CLUE.
It should be easy to add this without a long drawn out IETF standards
action process. Does the IESG want to be bothered with having to
review/process/meet to add value to an existing attribute?

I agree that adding new core CLUE syntax, messages etc should be
standards action required.

With regards to versioning I think any core protocol updates would be
handled by version number changes. Any additional attributes/values
other than those defined in the core protocol document would be handled
via the OPTIONS message.

So if we take the framework document my proposal would be that any
change to the existing protocol would require a "Standards Action"= ;
except for:
=C2=A0 7.1.1. Media Capture Attributes
=C2=A0 7.2.1. MCC Attributes
=C2=A0 7.3.1. Capture Scene attributes
=C2=A0 7.3.2. Capture Scene View attributes.
=C2=A0 9.2 Encoding Group attributes
where new values or new attributes could be added via expert
review/specification required. The use of these new attributes/values
would be signalled via an OPTIONS message.



=C2=A0 =C2=A0 I'm not sure if it's "weird" to use iana re= gistrations for xml
=C2=A0 =C2=A0 enumerations - if there is some preferred way to do this for = xml.

[MB] This is not unusual.=C2=A0 Take a look at RFC 6503. [/MB]


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


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




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

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


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

--089e013c65bc94600e0505677044-- From nobody Tue Oct 14 16:12:04 2014 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 3B7781A001E for ; Tue, 14 Oct 2014 16:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8uqmqFG8Whp for ; Tue, 14 Oct 2014 16:12:01 -0700 (PDT) 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 A4FA61A000F for ; Tue, 14 Oct 2014 16:12:01 -0700 (PDT) Received: from ppp118-209-159-157.lns20.mel8.internode.on.net ([118.209.159.157]:52783 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeBEf-0001qK-EV for clue@ietf.org; Wed, 15 Oct 2014 10:10:33 +1100 Message-ID: <543DADBA.9050107@nteczone.com> Date: Wed, 15 Oct 2014 10:11:54 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sI_dGGatSuTA8nqj_txFa9h-rN4 Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Tue, 14 Oct 2014 23:12:03 -0000 Hello Please see below marked [CNG]. Regards, Christian On 15/10/2014 6:58 AM, Mary Barnes wrote: > ..snip.. > > > > Putting them into IANA *might* make adding values > easier. It > depends on what registration procedure we choose. > > I am ok with making some things relatively each to add > to. But not > all. Some *ought* to have a high bar. For instance I > wouldn't want > to make it too easy to add a new viewType. > > [CNG] I agree some should have a higher bar. I wouldn't have > thought > viewType was one. What is it about viewType that you feel > should have a > high bar. > > > I didn't (though maybe Mary did). I was speaking in general about > whatever we put into IANA registries - we need to decide case by > case how high the bar should be. > > [MB] Nope. I was not speaking to view type. I's really hard to > follow attributions when people don't preface with initials or > whatever and expect an email program's rules to be sufficient. > Certainly, expert review with specification required could be an > option. I would be very wary of having a registry without such. I'm > not seeing in not having these things documented somewhere if we think > we need an IANA registry as is. [/MB] [CNG] I was referring to the above sentence "some *ought* to have a high bar. For instance I wouldn't want to make it too easy to add a new viewType." > > The specific items under discussion here are: > > - personTypeType > - viewType > - presentationType > - mobilityType > - ? scaleType > > Note that I put a question mark by scaleType. I think that one > deserves a high bar and to require version or option negotiation. > [CNG] Yes I agree this one does deserve a high bar. > > > For the others, I would be comfortable with expert review. And I > would not expect new clue version/option for it - just ignore > unknown values. > [CNG] I'm not sure about ignoring unknown values. There may be two identical captures only distinguished between by a value. How does the Consumer then distinguish between them? If we have the OPTIONS mechanism, why not use it to avoid the case where the MP sends the MC stuff it doesn't understand? ..snip.. From nobody Tue Oct 14 17:13:06 2014 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 B669D1A0086 for ; Tue, 14 Oct 2014 17:13:04 -0700 (PDT) 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 b5ttQlfUc2tL for ; Tue, 14 Oct 2014 17:13:03 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E63A1A006D for ; Tue, 14 Oct 2014 17:13:03 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-07v.sys.comcast.net with comcast id 3CCj1p0034zp9eg01CD2oC; Wed, 15 Oct 2014 00:13:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-07v.sys.comcast.net with comcast id 3CD21p0023Ge9ey01CD2QP; Wed, 15 Oct 2014 00:13:02 +0000 Message-ID: <543DBC0E.8090101@alum.mit.edu> Date: Tue, 14 Oct 2014 20:13:02 -0400 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: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> In-Reply-To: <543DADBA.9050107@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=1413331982; bh=DLGFz6X4DRmoTE6yAMJnXdC96sPdf0pD01o8A/DWSO0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vWzBGq70ern+ynP52XHiDmhEPw9c61nm0YFnfTCk3nDUxEwQ1lJVN8vCGfluafaB5 hctg8dXzBrcw379qq59vqDmdZgQaoIOiIjHDyHpbRo075Bfbi/r6h53OItw9BPZP8C y6LsuIMSk16rCayxRzLPRCkSclMKub5hcJp7T2C5HjOpoYMlUNOPHKEEJl9qKNDCI+ ZwKfHItvFLv48qQeLf/qhPO1E5vhngX8Tdm2UhkLzCQf1ZgzAjNxKwXStGTpwsJTAE rGUHyJK41iKcP7NZN+y2OrN9kxZvEEyKT2YOxTUeL8x6tzpLcauyLtmHVFXcpMvK8F cilyEe/p3SIog== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/z_EdcN19MwLkbS2kLMOlxBU9EBI Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Wed, 15 Oct 2014 00:13:05 -0000 On 10/14/14 7:11 PM, Christian Groves wrote: >> The specific items under discussion here are: >> >> - personTypeType >> - viewType >> - presentationType >> - mobilityType >> - ? scaleType >> >> Note that I put a question mark by scaleType. I think that one >> deserves a high bar and to require version or option negotiation. >> > [CNG] Yes I agree this one does deserve a high bar. >> >> >> For the others, I would be comfortable with expert review. And I >> would not expect new clue version/option for it - just ignore >> unknown values. >> > [CNG] I'm not sure about ignoring unknown values. There may be two > identical captures only distinguished between by a value. How does the > Consumer then distinguish between them? If we have the OPTIONS > mechanism, why not use it to avoid the case where the MP sends the MC > stuff it doesn't understand? Do you have something in mind to couple an option to the new value in iana? I guess part of the registration of the new value could be the clue version option that is required to use it. But that seems complex for what seems like a simple thing. That raises the bar for defining a new value. In addition to registering the new value you will have to also define the new option - requiring a schema URL to be registered. If you don't understand the values, then you make your decisions without regard to that. You still have the scene views and global views to guide you to a reasonable choice. And if you are going beyond that it may come down to human input anyway. A lesson from this discussion is that planning for extensions isn't so easy. Looks like it might take significant added work to get it so that expert review would be sufficient to do the right thing. In my experience that is one reason to set the bar high (standards action) as a way of kicking that can down the road. But I know the IESG is not in favor of that approach. Thanks, Paul From nobody Tue Oct 14 17:24:06 2014 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 A680B1A00A7 for ; Tue, 14 Oct 2014 17:23:52 -0700 (PDT) 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 4N2wh0UJzFUp for ; Tue, 14 Oct 2014 17:23:52 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BE61A00A6 for ; Tue, 14 Oct 2014 17:23:51 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-09v.sys.comcast.net with comcast id 3CPo1p0054s37d401CPrL9; Wed, 15 Oct 2014 00:23:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id 3CPq1p00K3Ge9ey01CPqp8; Wed, 15 Oct 2014 00:23:51 +0000 Message-ID: <543DBE96.60107@alum.mit.edu> Date: Tue, 14 Oct 2014 20:23:50 -0400 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: Mary Barnes References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413332631; bh=Vj/XXVoh54xR68fY4ScfblhFj6TwVSIF1x8iF4NX4uQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RH55Rbuajn4MNfMjiua3B6qOIfPnQPt8SQdVW54f6Y9hV94c/Qt0lEaFEyBUKDFuT wPstm/73RdZgkEAUUNDVmaOvIp9PWDDcwMEugbaju8iVJDAWcsfJZb/u305IUDc53m YIxBK+sVXDITnFNSLtYSORnUOOsLgvhP9kLZaZodGAs/WgP0QrP5zlIVb4HYeVWcCM LbGoSQCQCOncDJS2K8iv5R1q3y+Ymp5HHSQCltaQBnnAkAHntPZld42hH30kZY4EeA ffN3mwNzMZXys70CedBXWYwSDdk+gN5yxW6KoTe1Nb5z6pEltG02h69a57/jiKyMOo FkF8RYGlxnZ9g== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yan5Orh1mp573SyQqxVWTkNLhlI Cc: CLUE Subject: [clue] email usage styles 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, 15 Oct 2014 00:23:52 -0000 On 10/14/14 3:58 PM, Mary Barnes wrote: > [CNG] I agree some should have a higher bar. I wouldn't have thought > viewType was one. What is it about viewType that you feel should > have a > high bar. > > I didn't (though maybe Mary did). I was speaking in general about > whatever we put into IANA registries - we need to decide case by > case how high the bar should be. > > [MB] Nope. I was not speaking to view type. I's really hard to follow > attributions when people don't preface with initials or whatever and > expect an email program's rules to be sufficient. I guess that dig was addressed at me? IMO the problem is that people use incompatible conventions. I *detest* putting initials, especially when it is accompanied by violations of reply quoting conventions. The initials don't give any indication of the order of posts. And when accompanied by violations of the quoting conventions (as often happens) there is actually misdirection about the order of posts. And, unless you put your initials on every line, after a few replies it all becomes indecipherable. IMO the traditional mail quoting conventions work fine until things get complex enough to start trimming out the detail. When I do that I have no expectation that the trimmed identities will be known, or matter. I recognize that some other people detest the quoting conventions and *like* the initials. So I *tolerate* the mixed styles. It would probably be better if everyone agreed to do it one way or the other, but I don't expect that will happen. I've never investigated extensively, but I have the impression that some mail programs (Outlook?) don't do quoting right and have encouraged the use of initials. Thanks, Paul From nobody Tue Oct 14 17:58:55 2014 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 F0BEE1A00DB for ; Tue, 14 Oct 2014 17:58:52 -0700 (PDT) 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 6FR_nAatDPc0 for ; Tue, 14 Oct 2014 17:58:51 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725491A00D8 for ; Tue, 14 Oct 2014 17:58:50 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id p9so166478lbv.19 for ; Tue, 14 Oct 2014 17:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lgBGSEoBm9smEWlT5brjz0kHo1/ADdQsUtvLa1CoPm0=; b=yy/tg2SUxZAkpdhspy6uMJGo4Q74ErHWh+IhVgdz4qHinkgvbfUjjwi80Vf03qUGOm 7GHIuNd5JqYWOAPDXOCMSCGFa5c4u1zcxwxrVfdJlRFZ/a4o8v4fi0/BQqIeVjWLhoSv q/qZe52aX9Rt2xlweIVs3OCwRDqPyVZobIqay7/ySkkMKzZs9Xf5xcOcHrJHUsIcIYX5 ihqG7veOkFRNUo//q4TiQ5UokpB9xvseLF9QohRCHlYL+lgjjvEwDuKhZ+iuZ9+NrDnB GPJzrmNKEIH9H7Nf6mnAfI0q02o8UGVF3jTixhusBEhyNiIHFFTU1wByAfZY4Y8LFKgq G0OA== MIME-Version: 1.0 X-Received: by 10.152.27.67 with SMTP id r3mr8766926lag.19.1413334728726; Tue, 14 Oct 2014 17:58:48 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Tue, 14 Oct 2014 17:58:48 -0700 (PDT) In-Reply-To: <543DBE96.60107@alum.mit.edu> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DBE96.60107@alum.mit.edu> Date: Tue, 14 Oct 2014 19:58:48 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0158c3ce745f3b05056ba207 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GBGVcPhR-YsCXyN6jvQHmiyeS5Q Cc: CLUE Subject: Re: [clue] email usage styles 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, 15 Oct 2014 00:58:53 -0000 --089e0158c3ce745f3b05056ba207 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 14, 2014 at 7:23 PM, Paul Kyzivat wrote: > On 10/14/14 3:58 PM, Mary Barnes wrote: > > [CNG] I agree some should have a higher bar. I wouldn't have >> thought >> viewType was one. What is it about viewType that you feel should >> have a >> high bar. >> >> I didn't (though maybe Mary did). I was speaking in general about >> whatever we put into IANA registries - we need to decide case by >> case how high the bar should be. >> >> [MB] Nope. I was not speaking to view type. I's really hard to follow >> attributions when people don't preface with initials or whatever and >> expect an email program's rules to be sufficient. >> > > I guess that dig was addressed at me? > [MB2] It was a general comment about this thread and wasn't necessarily targeted at you. I was merely suggesting a reason for the confusion as to who said what. [/MB2] > > IMO the problem is that people use incompatible conventions. > I *detest* putting initials, especially when it is accompanied by > violations of reply quoting conventions. The initials don't give any > indication of the order of posts. And when accompanied by violations of the > quoting conventions (as often happens) there is actually misdirection about > the order of posts. And, unless you put your initials on every line, after > a few replies it all becomes indecipherable. > [MB2] I'm not at all sure what you mean in terms of "violations of reply quoting conventions". Can you please provide a pointer to such conventions? I use a block of text starting with [MBx] and ending with [/MBx]. I would think people would avoid commenting in the middle of the block as otherwise, I would agree it would then be impossible to tell the threads apart. [MB2] > > IMO the traditional mail quoting conventions work fine until things get > complex enough to start trimming out the detail. When I do that I have no > expectation that the trimmed identities will be known, or matter. > [MB2] What do you mean by "traditional"? Some systems use the ">"s and others use colors, indentation, etc. [/MB2] > > I recognize that some other people detest the quoting conventions and > *like* the initials. So I *tolerate* the mixed styles. It would probably be > better if everyone agreed to do it one way or the other, but I don't expect > that will happen. [MB2] Nope. Not gonna happen. It all depends upon the email program you use and IETF shouldn't be dictating UIs ;) [/MB2] > > I've never investigated extensively, but I have the impression that some > mail programs (Outlook?) don't do quoting right and have encouraged the use > of initials. > [MB2] I'm not sure what you mean by "quoting right" since many email programs do it differently. [MB2] > > Thanks, > Paul > > --089e0158c3ce745f3b05056ba207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 14, 2014 at 7:23 PM, Paul Kyzivat <pkyzivat@alum.mit.e= du> wrote:
On 10/14/14 3:58= PM, Mary Barnes wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 [CNG] I agree some should have a higher bar. I = wouldn't have thought
=C2=A0 =C2=A0 =C2=A0 =C2=A0 viewType was one. What is it about viewType tha= t you feel should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 high bar.

=C2=A0 =C2=A0 I didn't (though maybe Mary did). I was speaking in gener= al about
=C2=A0 =C2=A0 whatever we put into IANA registries - we need to decide case= by
=C2=A0 =C2=A0 case how high the bar should be.

[MB] Nope. I was not=C2=A0 speaking to view type.=C2=A0 I's really hard= to follow
attributions when people don't preface with initials or whatever and expect an email program's rules to be sufficient.

I guess that dig was addressed at me?
[MB2] It was a g= eneral comment about this thread and wasn't necessarily targeted at you= .=C2=A0 I was merely suggesting a reason for the confusion as to who said w= hat. [/MB2]=C2=A0

IMO the problem is that people use incompatible conventions.
I *detest* putting initials, especially when it is accompanied by violation= s of reply quoting conventions. The initials don't give any indication = of the order of posts. And when accompanied by violations of the quoting co= nventions (as often happens) there is actually misdirection about the order= of posts. And, unless you put your initials on every line, after a few rep= lies it all becomes indecipherable.
[MB2] I'm not = at all sure what you mean in terms of "violations of reply quoting con= ventions".=C2=A0 Can you please provide a pointer to such conventions?= =C2=A0 I use a block of text starting with [MBx] and ending with [/MBx].=C2= =A0 I would think people would avoid commenting in the middle of the block = as otherwise, I would agree it would then be impossible to tell the threads= apart. [MB2]

IMO the traditional mail quoting conventions work fine until things get com= plex enough to start trimming out the detail. When I do that I have no expe= ctation that the trimmed identities will be known, or matter.
[MB2] What do you mean by "traditional"?=C2=A0 Some syste= ms use the ">"s and others use colors, indentation, etc. =C2= =A0=C2=A0
[/MB2]=C2=A0

I recognize that some other people detest the quoting conventions and *like= * the initials. So I *tolerate* the mixed styles. It would probably be bett= er if everyone agreed to do it one way or the other, but I don't expect= that will happen.
[MB2] Nope. Not gonna happen. It all de= pends upon the email program you use and IETF shouldn't be dictating UI= s ;) [/MB2]=C2=A0
=C2=A0

I've never investigated extensively, but I have the impression that som= e mail programs (Outlook?) don't do quoting right and have encouraged t= he use of initials.
[MB2] I'm not sure what you me= an by "quoting right" since many email programs do it differently= . [MB2]=C2=A0

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


--089e0158c3ce745f3b05056ba207-- From nobody Tue Oct 14 19:01:56 2014 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 62A991A0119 for ; Tue, 14 Oct 2014 19:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 sA7QQxwN5tgJ for ; Tue, 14 Oct 2014 19:01:53 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AE8AE1A0118 for ; Tue, 14 Oct 2014 19:01:53 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C55DCC94BD; Tue, 14 Oct 2014 22:01:47 -0400 (EDT) Date: Tue, 14 Oct 2014 22:01:47 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20141015020147.GU83009@verdi> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DBE96.60107@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <543DBE96.60107@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Z07sW3AHkPyUAnvaF7Fg11Sef20 Cc: CLUE Subject: Re: [clue] email usage styles 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, 15 Oct 2014 02:01:55 -0000 Paul Kyzivat wrote: > On 10/14/14 3:58 PM, Mary Barnes wrote: > >> [MB] Nope. I was not speaking to view type. I's really hard to follow >> attributions when people don't preface with initials or whatever and >> expect an email program's rules to be sufficient. > > IMO the problem is that people use incompatible conventions. +1 > I *detest* putting initials, especially when it is accompanied by > violations of reply quoting conventions. +1 > The initials don't give any indication of the order of posts. And > when accompanied by violations of the quoting conventions (as often > happens) there is actually misdirection about the order of posts. > And, unless you put your initials on every line, after a few replies > it all becomes indecipherable. +1 > IMO the traditional mail quoting conventions work fine until things get > complex enough to start trimming out the detail. When I do that I have > no expectation that the trimmed identities will be known, or matter. Please let _me_ know if you have difficulty following my attributions. I try very hard to boil things down so as to be easy to follow, and I make sure there are carriage-returns every 70 characters or so. > I recognize that some other people detest the quoting conventions and > *like* the initials. So I *tolerate* the mixed styles. +1 (Very often, people who like initials use them so sparingly that I have real trouble distinguishing what text is theirs.) And please note: a number of us use mail-readers that very nicely color the quoted text, which to me at least makes the difference between being able to quickly follow the discussion or having to skip over it. :^( > It would probably be better if everyone agreed to do it one way or > the other, but I don't expect that will happen. Clearly, it _won't_ happen. Too many of us _have_to_ use mail readers which don't follow any reasonable (IMHO) quoting rules. :^( -- John Leslie From nobody Wed Oct 15 13:43:04 2014 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 CE4E91ACD36 for ; Wed, 15 Oct 2014 13:42:57 -0700 (PDT) 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 qobGjNG6M7ne for ; Wed, 15 Oct 2014 13:42:56 -0700 (PDT) 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 D35011A88F3 for ; Wed, 15 Oct 2014 13:42:55 -0700 (PDT) Received: from ppp118-209-159-157.lns20.mel8.internode.on.net ([118.209.159.157]:52432 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XeVNl-0001EB-EZ for clue@ietf.org; Thu, 16 Oct 2014 07:41:17 +1100 Message-ID: <543EDC49.6080700@nteczone.com> Date: Thu, 16 Oct 2014 07:42:49 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> In-Reply-To: <543DBC0E.8090101@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/q0sgx74y2qlWNLZbe8wLe_SERnM Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Wed, 15 Oct 2014 20:42:58 -0000 Hello Paul, Please see below. Regards, Christian On 15/10/2014 11:13 AM, Paul Kyzivat wrote: > On 10/14/14 7:11 PM, Christian Groves wrote: > >>> The specific items under discussion here are: >>> >>> - personTypeType >>> - viewType >>> - presentationType >>> - mobilityType >>> - ? scaleType >>> >>> Note that I put a question mark by scaleType. I think that one >>> deserves a high bar and to require version or option negotiation. >>> >> [CNG] Yes I agree this one does deserve a high bar. >>> >>> >>> For the others, I would be comfortable with expert review. And I >>> would not expect new clue version/option for it - just ignore >>> unknown values. >>> >> [CNG] I'm not sure about ignoring unknown values. There may be two >> identical captures only distinguished between by a value. How does the >> Consumer then distinguish between them? If we have the OPTIONS >> mechanism, why not use it to avoid the case where the MP sends the MC >> stuff it doesn't understand? > > Do you have something in mind to couple an option to the new value in > iana? [CNG] I was thinking that someone would register the option with IANA with a pointer to a specification. The specification indicates what the additional attributes/values are. This provides the link. Alternatively the registry could be of a structure: CLUE OPTIONS Name Description Reference foo Enables foo RFCqwer CLUE Media Capture Attributes Name Description Reference foob whatecer RFCqwer I don't think its up to the registry to enforce protocol behaviour. I think the only function of the registry is to ensure that there's no identifier conflict. > > I guess part of the registration of the new value could be the clue > version option that is required to use it. But that seems complex for > what seems like a simple thing. That raises the bar for defining a new > value. In addition to registering the new value you will have to also > define the new option - requiring a schema URL to be registered. [CNG] The protocol says "An option is characterized by a name, an XML schema of reference where the option is defined, and the version of the protocol which the option refers to." I think the version could be optional. Ideally the addition of an attribute should be dependent on any particular version of the base (default behaviour). However if an attribute did need a certain CLUE protocol version then it could indicate the minimum version. > > If you don't understand the values, then you make your decisions > without regard to that. You still have the scene views and global > views to guide you to a reasonable choice. And if you are going beyond > that it may come down to human input anyway. [CNG] Yes, however we have a mechanism to avoid that situation. > > A lesson from this discussion is that planning for extensions isn't so > easy. Looks like it might take significant added work to get it so > that expert review would be sufficient to do the right thing. In my > experience that is one reason to set the bar high (standards action) > as a way of kicking that can down the road. But I know the IESG is not > in favor of that approach. [CNG] I don't see the significant work. In either expert review or standards action we'd need to establish rules for updates. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Oct 15 13:52:48 2014 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 367321ACD4E for ; Wed, 15 Oct 2014 13:52:46 -0700 (PDT) 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 E5_e_kadijbZ for ; Wed, 15 Oct 2014 13:52:43 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2761ACD36 for ; Wed, 15 Oct 2014 13:52:42 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id q1so1775969lam.36 for ; Wed, 15 Oct 2014 13:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKxXwvl57Ogt5HDd3zJA2TFxnFL+eXzGQN6qLruFMRo=; b=NKBtFpYZjUxLcuHeV86wRcsI5sArUcuUHMC5iwJ+Og1ipbrHxhUM+9IjiqWz486Gny qXNnuPH5Gqbwr1liDSdp2QyYIQrZL/idT0M/Jt2VGeooOraOh5v+AUzqzgn5FTUTXkRF QrF+EwK+RnOOdTRDOC5WNjw1XLRYopJRM09KQ5I3z7yzTDOD7E7AilxQKy74xBqFUHXQ FVTjKvdYOgE5qFRWi6GG3Nr5FLH1BHh7+CZX/jj3y9q70fhyRZOh3VtV/S0YfyDLb0Mv SHlqV2Xo49IR+es1/KxT5Isl5zgBBAANAabPCNGxCkcyoLCfINNpczG+LL8Kml5rtPY5 IQ1A== MIME-Version: 1.0 X-Received: by 10.152.87.7 with SMTP id t7mr15175689laz.74.1413406360985; Wed, 15 Oct 2014 13:52:40 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Wed, 15 Oct 2014 13:52:40 -0700 (PDT) In-Reply-To: <543EDC49.6080700@nteczone.com> References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> <543EDC49.6080700@nteczone.com> Date: Wed, 15 Oct 2014 15:52:40 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=001a11c3505a11e33605057c509c Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1zvOgsNkcGQyv78CoM-uxxqtdDA Cc: CLUE Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Wed, 15 Oct 2014 20:52:46 -0000 --001a11c3505a11e33605057c509c Content-Type: text/plain; charset=UTF-8 One comment at the end [MB]. Mary. On Wed, Oct 15, 2014 at 3:42 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello Paul, > > Please see below. > > Regards, Christian > > On 15/10/2014 11:13 AM, Paul Kyzivat wrote: > >> On 10/14/14 7:11 PM, Christian Groves wrote: >> >> The specific items under discussion here are: >>>> >>>> - personTypeType >>>> - viewType >>>> - presentationType >>>> - mobilityType >>>> - ? scaleType >>>> >>>> Note that I put a question mark by scaleType. I think that one >>>> deserves a high bar and to require version or option negotiation. >>>> >>>> [CNG] Yes I agree this one does deserve a high bar. >>> >>>> >>>> >>>> For the others, I would be comfortable with expert review. And I >>>> would not expect new clue version/option for it - just ignore >>>> unknown values. >>>> >>>> [CNG] I'm not sure about ignoring unknown values. There may be two >>> identical captures only distinguished between by a value. How does the >>> Consumer then distinguish between them? If we have the OPTIONS >>> mechanism, why not use it to avoid the case where the MP sends the MC >>> stuff it doesn't understand? >>> >> >> Do you have something in mind to couple an option to the new value in >> iana? >> > [CNG] I was thinking that someone would register the option with IANA with > a pointer to a specification. The specification indicates what the > additional attributes/values are. This provides the link. > Alternatively the registry could be of a structure: > > CLUE OPTIONS > Name Description Reference > foo Enables foo RFCqwer > > CLUE Media Capture Attributes > Name Description Reference > foob whatecer RFCqwer > > I don't think its up to the registry to enforce protocol behaviour. I > think the only function of the registry is to ensure that there's no > identifier conflict. > > >> I guess part of the registration of the new value could be the clue >> version option that is required to use it. But that seems complex for what >> seems like a simple thing. That raises the bar for defining a new value. In >> addition to registering the new value you will have to also define the new >> option - requiring a schema URL to be registered. >> > [CNG] The protocol says "An option is characterized by a name, an XML > schema of reference where the option is defined, and the version of the > protocol which the option refers to." I think the version could be > optional. Ideally the addition of an attribute should be dependent on any > particular version of the base (default behaviour). However if an attribute > did need a certain CLUE protocol version then it could indicate the minimum > version. > > >> If you don't understand the values, then you make your decisions without >> regard to that. You still have the scene views and global views to guide >> you to a reasonable choice. And if you are going beyond that it may come >> down to human input anyway. >> > [CNG] Yes, however we have a mechanism to avoid that situation. > > >> A lesson from this discussion is that planning for extensions isn't so >> easy. Looks like it might take significant added work to get it so that >> expert review would be sufficient to do the right thing. In my experience >> that is one reason to set the bar high (standards action) as a way of >> kicking that can down the road. But I know the IESG is not in favor of that >> approach. >> > [CNG] I don't see the significant work. In either expert review or > standards action we'd need to establish rules for updates. [MB] I don't either. Paul, can you further explain or provide some details of the IESG concern. That's the first I've heard of such. [/MB] > > > >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a11c3505a11e33605057c509c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One comment at the end [MB].

Mary.
<= div class=3D"gmail_extra">
On Wed, Oct 15, 20= 14 at 3:42 PM, Christian Groves <Christian.Groves@nteczone.com= > wrote:
Hello Paul,

Please see below.

Regards, Christian

On 15/10/2014 11:13 AM, Paul Kyzivat wrote:
On 10/14/14 7:11 PM, Christian Groves wrote:

=C2=A0 =C2=A0 The specific items under discussion here are:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - personTypeType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - viewType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - presentationType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - mobilityType
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 - ? scaleType

=C2=A0 =C2=A0 Note that I put a question mark by scaleType. I think that on= e
=C2=A0 =C2=A0 deserves a high bar and to require version or option negotiat= ion.

[CNG] Yes I agree this one does deserve a high bar.


=C2=A0 =C2=A0 For the others, I would be comfortable with expert review. An= d I
=C2=A0 =C2=A0 would not expect new clue version/option for it - just ignore=
=C2=A0 =C2=A0 unknown values.

[CNG] I'm not sure about ignoring unknown values. There may be two
identical captures only distinguished between by a value. How does the
Consumer then distinguish between them? If we have the OPTIONS
mechanism, why not use it to avoid the case where the MP sends the MC
stuff it doesn't understand?

Do you have something in mind to couple an option to the new value in iana?=
[CNG] I was thinking that someone would register the option with IANA with = a pointer to a specification. The specification indicates what the addition= al attributes/values are. This provides the link.
Alternatively the registry could be of a structure:

CLUE OPTIONS
Name=C2=A0 Description Reference
foo=C2=A0 =C2=A0Enables foo=C2=A0 RFCqwer

CLUE Media Capture Attributes
Name=C2=A0 Description Reference
foob=C2=A0 whatecer=C2=A0 =C2=A0 RFCqwer

I don't think its up to the registry to enforce protocol behaviour. I t= hink the only function of the registry is to ensure that there's no ide= ntifier conflict.


I guess part of the registration of the new value could be the clue version= option that is required to use it. But that seems complex for what seems l= ike a simple thing. That raises the bar for defining a new value. In additi= on to registering the new value you will have to also define the new option= - requiring a schema URL to be registered.
 [CNG] The protocol says "An option is characterized by a name, an XML = schema of reference where the option is defined, and the version of the pro= tocol which the option refers to." I think the version could be option= al. Ideally the addition of an attribute should be dependent on any particu= lar version of the base (default behaviour). However if an attribute did ne= ed a certain CLUE protocol version then it could indicate the minimum versi= on.


If you don't understand the values, then you make your decisions withou= t regard to that. You still have the scene views and global views to guide = you to a reasonable choice. And if you are going beyond that it may come do= wn to human input anyway.
 [CNG] Yes, however we have a mechanism to avoid that situation.


A lesson from this discussion is that planning for extensions isn't so = easy. Looks like it might take significant added work to get it so that exp= ert review would be sufficient to do the right thing. In my experience that= is one reason to set the bar high (standards action) as a way of kicking t= hat can down the road. But I know the IESG is not in favor of that approach= .
 [CNG] I don't see the significant work. In either expert review or stan= dards action we'd need to establish rules for updates.
[MB] I don't either. Paul, can you further explain or provide some det= ails of the IESG concern.=C2=A0 That's the first I've heard of such= . =C2=A0[/MB]



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

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


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

--001a11c3505a11e33605057c509c-- From nobody Thu Oct 16 08:43:37 2014 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 487021A3BA9 for ; Thu, 16 Oct 2014 08:43:34 -0700 (PDT) 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 CWX3Hk8yT50P for ; Thu, 16 Oct 2014 08:43:33 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199D91A3BA2 for ; Thu, 16 Oct 2014 08:43:32 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-04v.sys.comcast.net with comcast id 3rj51p00F4yXVJQ01rjYxw; Thu, 16 Oct 2014 15:43:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 3rjX1p00Q3Ge9ey01rjY4Y; Thu, 16 Oct 2014 15:43:32 +0000 Message-ID: <543FE7A3.6060409@alum.mit.edu> Date: Thu, 16 Oct 2014 11:43:31 -0400 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: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> <543EDC49.6080700@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413474212; bh=ssvCQ3f/ZiqvSJtc2jqDY3DuCzrISZnZLn7wMLyTfqs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rfNHEg82JLseP37UKB4uf4ZVogQpoHe0trgnKJJdrOKwdeQ6RPSHTr8nHz3lWonkm 10LgFhqfQlOlV0gBAO28/g0aTJtydsw1V8D5nNApCmm0ajiiSt76TUJeWYxH5T6zN7 kfvOVkfFE3MAf8tsS/6LMULzPm6FVQrAQK2wcj6a9CmyD2De4pDUpu8AuIDlrq2ZlI FqzO6O+lBC4zYOJw/n+r4wIzONnJCWVO/7njbRjb3KANxONaUKODrVMysuCPdJs1J6 ohSr8z+mm626OC+BuaCMCA3ZkBABIm007TuZR5nK0AdFKKH/lGUEbB0EDb2AH3cWCR /G0fol6T1zZPQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/R1uqh_S_35NQ66cwo2N_jC3Ana0 Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 16 Oct 2014 15:43:34 -0000 On 10/15/14 4:52 PM, Mary Barnes wrote: > A lesson from this discussion is that planning for extensions > isn't so easy. Looks like it might take significant added work > to get it so that expert review would be sufficient to do the > right thing. In my experience that is one reason to set the bar > high (standards action) as a way of kicking that can down the > road. But I know the IESG is not in favor of that approach. > > [CNG] I don't see the significant work. In either expert review or > standards action we'd need to establish rules for updates. > > [MB] I don't either. Paul, can you further explain or provide some > details of the IESG concern. That's the first I've heard of such. [/MB] If changes require Standards Action, then we can (arguably) assume that the process of getting the change approved will consider all the ramifications and filter out bad ideas, even though we haven't defined any specific rules. If the changes only require expert review, then we *might* make the same leap of faith. But that puts a lot of burden on the expert. I am an expert for a couple of registries, and the standards are not very clear on what should/shouldn't be allowed. While some might enjoy the power that gives, I don't appreciate it. IMO, if we call for Expert Review, then we should also provide the criteria that the expert is to apply to decide what to accept and what to reject. The significant work is to figure out those criteria. I don't mean to imply that it is a huge task, but its the kind of thing that can get bogged down. Thanks, Paul From nobody Thu Oct 16 08:54:23 2014 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 E07C41A8035 for ; Thu, 16 Oct 2014 08:54:16 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2vsYbosU4Xht for ; Thu, 16 Oct 2014 08:54:15 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E3F1A82E2 for ; Thu, 16 Oct 2014 08:54:15 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-05v.sys.comcast.net with comcast id 3rtx1p00353iAfU01ruELc; Thu, 16 Oct 2014 15:54:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id 3ruE1p00K3Ge9ey01ruE6E; Thu, 16 Oct 2014 15:54:14 +0000 Message-ID: <543FEA26.9060608@alum.mit.edu> Date: Thu, 16 Oct 2014 11:54:14 -0400 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: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> <543EDC49.6080700@nteczone.com> In-Reply-To: <543EDC49.6080700@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=1413474854; bh=yb2rr4wZCXhZJwIQpPcDCZFjH7Q1INrNXSxwy+IIcz0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=joat2GixPaiqEf2HoWYbrlwDBKZ/8CkG4P0PXvet6m7IWENoxwCaHd849AHmWbPlP j++hhvIzAjUkOVa24ff41rlrTnWEr7FMedZsxXu6dgthbOr/Q+YmUFBUlyKD/s2JXs 3uNo8Hg45wi62EzeO2UgM58X6oJ/uE5c+U7QKZ/wpH6AsykeMujgfoIr/MZoOCcnpf LQmW7Xz4kdSpoPl4ZDHSxNVXsrPtGTaK50aRTpeBwaY2V+82JGvIvpnoc25mcN72Fd 8rvZX6o9/0VE5pnhPwvu4BNZ5Kaq2lf15lOKNa651P1U1T5m3soP/RFvvzPmclXImv vnT9N4vHRPjSQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MXCSYPttRx3NciFs-hA6AS98ous Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 16 Oct 2014 15:54:17 -0000 On 10/15/14 4:42 PM, Christian Groves wrote: >> Do you have something in mind to couple an option to the new value in >> iana? > [CNG] I was thinking that someone would register the option with IANA > with a pointer to a specification. The specification indicates what the > additional attributes/values are. This provides the link. > Alternatively the registry could be of a structure: > > CLUE OPTIONS > Name Description Reference > foo Enables foo RFCqwer > > CLUE Media Capture Attributes > Name Description Reference > foob whatecer RFCqwer > > I don't think its up to the registry to enforce protocol behaviour. I > think the only function of the registry is to ensure that there's no > identifier conflict. OK, that works. Then the policy for both CLUE OPTIONS and CLUE Media Capture Attributes would need to require something to reference. Are you thinking Standards Action for that? If so, then the bar for a new attribute value is still Standards Action. I thought you were asking for a lower bar there. For instance, this would most likely preclude definition of vendor-specific values. (Whether you consider that a good thing or a bad thing.) >> I guess part of the registration of the new value could be the clue >> version option that is required to use it. But that seems complex for >> what seems like a simple thing. That raises the bar for defining a new >> value. In addition to registering the new value you will have to also >> define the new option - requiring a schema URL to be registered. > [CNG] The protocol says "An option is characterized by a name, an XML > schema of reference where the option is defined, and the version of the > protocol which the option refers to." I think the version could be > optional. Ideally the addition of an attribute should be dependent on > any particular version of the base (default behaviour). However if an > attribute did need a certain CLUE protocol version then it could > indicate the minimum version. I think it would have to specify the major versions it works with, and the lowest minor version for each of those. (I suppose there could be a default to 1.0, but I don't see the value in that. If you have to specify it then you will have to think about it!) Thanks, Paul From nobody Thu Oct 16 09:18:09 2014 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 9E0171A7014 for ; Thu, 16 Oct 2014 09:18:08 -0700 (PDT) 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 u8_UUmUUDnin for ; Thu, 16 Oct 2014 09:18:07 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690A01A6FE8 for ; Thu, 16 Oct 2014 09:18:07 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with comcast id 3sGZ1p0014yXVJQ01sJ6TQ; Thu, 16 Oct 2014 16:18:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 3sJ61p0033Ge9ey01sJ65Y; Thu, 16 Oct 2014 16:18:06 +0000 Message-ID: <543FEFBD.9030807@alum.mit.edu> Date: Thu, 16 Oct 2014 12:18:05 -0400 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: Mary Barnes References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DBE96.60107@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413476286; bh=HUutuT1GCV0+jYuL1yF5z73gqcgXnspi3YB5cHGeC38=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=L47MCxhewhmzRmsQMQVEQ1RiUVgpzW8zlj3hjaVLaMzJEZTbwTSntIUyICX+7SGuQ F25/sIDsrNZRbWARQ7YhuWP25o+YsN5+jjOalK0lHTfwQYvR9kU70IuEUhzo9mJ3j3 iv0qEHympP6zzDfbUcn+J2wUKwwc2c4OF4EMxzqfw0buLOoyWvFjsFINz2s/zsTa1r qBbEfz5OGnFJun6fFnrHWld3HKlKZHxqaqNpuZ5LQqvh4Th5i7deDj9p4G+5bgrdRn 7rhgrVRK9f1V1uwONbyi5/FnaX6qMbiXRhS3c2Ka0Z6jpFiJjAZmEQyYM9l9LjP+Gr XFlqlxKdmEs2A== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/SKBDFVAvMTlmG6WSx0UD7EMAIGI Cc: CLUE Subject: Re: [clue] email usage styles 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, 16 Oct 2014 16:18:08 -0000 On 10/14/14 8:58 PM, Mary Barnes wrote: > > > On Tue, Oct 14, 2014 at 7:23 PM, Paul Kyzivat > wrote: [snip] > IMO the problem is that people use incompatible conventions. > I *detest* putting initials, especially when it is accompanied by > violations of reply quoting conventions. The initials don't give any > indication of the order of posts. And when accompanied by violations > of the quoting conventions (as often happens) there is actually > misdirection about the order of posts. And, unless you put your > initials on every line, after a few replies it all becomes > indecipherable. > > [MB2] I'm not at all sure what you mean in terms of "violations of reply > quoting conventions". Can you please provide a pointer to such > conventions? I use a block of text starting with [MBx] and ending with > [/MBx]. I would think people would avoid commenting in the middle of > the block as otherwise, I would agree it would then be impossible to > tell the threads apart. [MB2] > > > IMO the traditional mail quoting conventions work fine until things > get complex enough to start trimming out the detail. When I do that > I have no expectation that the trimmed identities will be known, or > matter. > > [MB2] What do you mean by "traditional"? Some systems use the ">"s and > others use colors, indentation, etc. > [/MB2] IMO the "traditional" approach is the "> "s. And it includes "indentation" in the sense that each subsequent reply inserts a new layer of "> "s. I don't know where it is documented. Presumably many places since a variety of mail programs implement this approach. I'm pretty sure this approach predates use of colors, since it predated the widespread availability of color. In the mail program I use (Thunderbird), quoting using "> " is rendered using continuous vertical lines (replacing the ">"), making it quite clear what goes together and where reply commentary has been inserted, to many levels of replies. > I recognize that some other people detest the quoting conventions > and *like* the initials. So I *tolerate* the mixed styles. It would > probably be better if everyone agreed to do it one way or the other, > but I don't expect that will happen. > > [MB2] Nope. Not gonna happen. It all depends upon the email program you > use and IETF shouldn't be dictating UIs ;) [/MB2] I understand, and tolerate it, while grumbling to myself (and occasionally in public, like now). > I've never investigated extensively, but I have the impression that > some mail programs (Outlook?) don't do quoting right and have > encouraged the use of initials. > > [MB2] I'm not sure what you mean by "quoting right" since many email > programs do it differently. [MB2] Of course the "right" way is the way *I* prefer. :-) The problem with the [foo] ... [/foo] approach is that it is hard to follow when commentary is inserted in the middle of such a block. And the sequence in which comments were added by different authors isn't apparent. (Nor for a single author unless they remember to use [foo2], [foo3] etc.) And it breaks down entirely when you start trimming the text down to focus the conversation. The thing about the "> " approach is that it tags every line with the nesting level. So even with extensive trimming you can still discern at least the to and fro of the conversation, even if you can't tell exactly who said it. I would find it interesting to take a message from an old thread with a lot of discussion in it, and see exactly what it looks like in all the popular mail programs. Of course this is just tilting at windmills. Thanks, Paul Thanks, Paul From nobody Thu Oct 16 16:59:05 2014 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 05B0A1A8883 for ; Thu, 16 Oct 2014 16:59:04 -0700 (PDT) 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 S8ewUcg4NOLO for ; Thu, 16 Oct 2014 16:59:01 -0700 (PDT) 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 217A11A87C5 for ; Thu, 16 Oct 2014 16:59:01 -0700 (PDT) Received: from ppp118-209-12-240.lns20.mel4.internode.on.net ([118.209.12.240]:51282 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xeuuo-0001Kj-At for clue@ietf.org; Fri, 17 Oct 2014 10:57:06 +1100 Message-ID: <54405BBC.8020706@nteczone.com> Date: Fri, 17 Oct 2014 10:58:52 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> <543EDC49.6080700@nteczone.com> <543FEA26.9060608@alum.mit.edu> In-Reply-To: <543FEA26.9060608@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mhPqcaHtdoLkHs4rpES3w3Cjb34 Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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: Thu, 16 Oct 2014 23:59:04 -0000 Hello Paul, Please see below. Regards, Christian On 17/10/2014 2:54 AM, Paul Kyzivat wrote: > On 10/15/14 4:42 PM, Christian Groves wrote: > >>> Do you have something in mind to couple an option to the new value in >>> iana? >> [CNG] I was thinking that someone would register the option with IANA >> with a pointer to a specification. The specification indicates what the >> additional attributes/values are. This provides the link. >> Alternatively the registry could be of a structure: >> >> CLUE OPTIONS >> Name Description Reference >> foo Enables foo RFCqwer >> >> CLUE Media Capture Attributes >> Name Description Reference >> foob whatecer RFCqwer >> >> I don't think its up to the registry to enforce protocol behaviour. I >> think the only function of the registry is to ensure that there's no >> identifier conflict. > > OK, that works. Then the policy for both CLUE OPTIONS and CLUE Media > Capture Attributes would need to require something to reference. Are > you thinking Standards Action for that? > > If so, then the bar for a new attribute value is still Standards > Action. I thought you were asking for a lower bar there. [CNG] No I was thinking specification required, with a reference to the specification. It still means it has to be a public document but doesn't force a standards track RFC. > > For instance, this would most likely preclude definition of > vendor-specific values. (Whether you consider that a good thing or a > bad thing.) [CNG] Probably not a bad thing... but I think if you make it so that any SDO/Forum could register something it will probably mean that it will decrease the number of vendor specific optimizations. To make sure that vendor specific additions didn't interfere with IANA registered ones we could assign a value range for them to play with. i.e. Vendor specific options and attributes could start with a "v-", e.g. v-foo. > >>> I guess part of the registration of the new value could be the clue >>> version option that is required to use it. But that seems complex for >>> what seems like a simple thing. That raises the bar for defining a new >>> value. In addition to registering the new value you will have to also >>> define the new option - requiring a schema URL to be registered. >> [CNG] The protocol says "An option is characterized by a name, an XML >> schema of reference where the option is defined, and the version of the >> protocol which the option refers to." I think the version could be >> optional. Ideally the addition of an attribute should be dependent on >> any particular version of the base (default behaviour). However if an >> attribute did need a certain CLUE protocol version then it could >> indicate the minimum version. > > I think it would have to specify the major versions it works with, and > the lowest minor version for each of those. (I suppose there could be > a default to 1.0, but I don't see the value in that. If you have to > specify it then you will have to think about it!) [CNG] I'm not fond of backwards incompatible changes. Hopefully we see clue v1.1 and not v2. I think in going for a new major version it would have to take into account the existing attributes to see if they are still compatible. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 16 17:05:32 2014 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 4ADB11A88E3 for ; Thu, 16 Oct 2014 17:05:29 -0700 (PDT) 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 UTu2Lsc5GhKB for ; Thu, 16 Oct 2014 17:05:26 -0700 (PDT) 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 5ACBA1A87E0 for ; Thu, 16 Oct 2014 17:05:26 -0700 (PDT) Received: from ppp118-209-12-240.lns20.mel4.internode.on.net ([118.209.12.240]:51470 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xev12-0002Vz-NS for clue@ietf.org; Fri, 17 Oct 2014 11:03:32 +1100 Message-ID: <54405D3F.6000402@nteczone.com> Date: Fri, 17 Oct 2014 11:05:19 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <542B2164.1060207@alum.mit.edu> <542D197D.9040808@unina.it> <542D8A5C.5050004@alum.mit.edu> <543216B5.8080606@nteczone.com> <543BF8D9.20302@alum.mit.edu> <543C686F.8010907@nteczone.com> <543D76D9.3080506@alum.mit.edu> <543DADBA.9050107@nteczone.com> <543DBC0E.8090101@alum.mit.edu> <543EDC49.6080700@nteczone.com> <543FE7A3.6060409@alum.mit.edu> In-Reply-To: <543FE7A3.6060409@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/EgG67Nr7yUiO6sMX8Ui7oT1Bzn4 Subject: Re: [clue] comments on draft-ietf-clue-data-model-schema-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, 17 Oct 2014 00:05:29 -0000 Hello Paul, I did a similar task for Megaco (see RFC5615) to define what the expert has to check. I think elements of clause 5 would be appropriate. I can work on a text proposal for CLUE IANA considerations, it will probably be a couple of weeks before I have something though. Regards, Christian On 17/10/2014 2:43 AM, Paul Kyzivat wrote: > On 10/15/14 4:52 PM, Mary Barnes wrote: > >> A lesson from this discussion is that planning for extensions >> isn't so easy. Looks like it might take significant added work >> to get it so that expert review would be sufficient to do the >> right thing. In my experience that is one reason to set the bar >> high (standards action) as a way of kicking that can down the >> road. But I know the IESG is not in favor of that approach. >> >> [CNG] I don't see the significant work. In either expert review or >> standards action we'd need to establish rules for updates. >> >> [MB] I don't either. Paul, can you further explain or provide some >> details of the IESG concern. That's the first I've heard of such. >> [/MB] > > If changes require Standards Action, then we can (arguably) assume > that the process of getting the change approved will consider all the > ramifications and filter out bad ideas, even though we haven't defined > any specific rules. > > If the changes only require expert review, then we *might* make the > same leap of faith. But that puts a lot of burden on the expert. I am > an expert for a couple of registries, and the standards are not very > clear on what should/shouldn't be allowed. While some might enjoy the > power that gives, I don't appreciate it. IMO, if we call for Expert > Review, then we should also provide the criteria that the expert is to > apply to decide what to accept and what to reject. The significant > work is to figure out those criteria. I don't mean to imply that it is > a huge task, but its the kind of thing that can get bogged down. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sat Oct 18 14:16:25 2014 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 D60981A1A83; Sat, 18 Oct 2014 14:16:20 -0700 (PDT) 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 rWcTqbBlZzde; Sat, 18 Oct 2014 14:16:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8691A1A79; Sat, 18 Oct 2014 14:16:19 -0700 (PDT) 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.6.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141018211619.25932.62629.idtracker@ietfa.amsl.com> Date: Sat, 18 Oct 2014 14:16:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/__WkQGbKKNzsYesy7WgH43Q5TGk Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-03.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: Sat, 18 Oct 2014 21:16:21 -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 : Mapping RTP streams to CLUE media captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-03.txt Pages : 15 Date : 2014-10-18 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-03 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 Mon Oct 20 11:16:38 2014 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 8D4581A8ADB for ; Mon, 20 Oct 2014 11:16:35 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uxL60FRRWJAp for ; Mon, 20 Oct 2014 11:16:32 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E08F1A8AF1 for ; Mon, 20 Oct 2014 11:15:55 -0700 (PDT) Received: from [216.82.254.19:3805] by server-10.bemta-7.messagelabs.com id 3B/E0-15477-A5155445; Mon, 20 Oct 2014 18:15:54 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-96.messagelabs.com!1413828951!13711848!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21656 invoked from network); 20 Oct 2014 18:15:53 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-12.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 20 Oct 2014 18:15:53 -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; Mon, 20 Oct 2014 11:12:25 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 20 Oct 2014 11:12:24 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 20 Oct 2014 11:12:10 -0700 Thread-Topic: Global Views and media type - RE: [clue] Updates in framework-17 Thread-Index: Ac/skOWwmv/QLKqASYWISYaq2wfoEg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97760@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8RjIOb1OKauAc3qSxfiqrq52jn8 Subject: [clue] Global Views and media type - RE: Updates in framework-17 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, 20 Oct 2014 18:16:35 -0000 Hi Paul, Responses Inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, October 14, 2014 11:28 AM > To: clue@ietf.org > Subject: Re: [clue] Updates in framework-17 >=20 > On 10/13/14 7:21 PM, Christian Groves wrote: > > Hello > > > >> > >>> Global View List: A list of Global Views included in an Advertisement= . > >> > >> I think we need to clarify: does a Global View List contain only > >> Global Views of a single media type? (This implies that we need a > >> separate Global View List for each media type.) Or is there a single > >> Global View List containing Global Views of different types? The data > >> model currently has followed the second model. > > [CNG] Scenes contains different types of media (e.g. audio and video) s= o > > would then a list of scenes (Global View List) then also refers to > > different types of media? [Duckworth, Mark] I will add a statement that "A Global View List may inclu= de Global Views of different media types" > - Each scene contains a number of captures, > each of a particular media type. > - Each scene contains a single sceneViews element. > That contains a number of sceneView elements. > This includes sceneView elements of differing media types. > - Each sceneView element contains a mediaCaptureIDs element > referencing a number of mediaCapture elements in the scene > and all of a single media type. > - The advertisement contains a *single* globalViews element, > that contains multiple globalView elements. > (Hence it had better encompass multiple media types.) > - The globalView element references multiple sceneView elements. >=20 > There is currently no statement whether or not all the sceneView > elements referenced by a globalView must be of the same type. [Duckworth, Mark] Yes there is, in the definition of Global View in the fra= mework: "A set of references to one or more Capture Scene Views of the same media t= ype..."=20 I think this is correct and we should stick with it. >=20 > We must make a choice here: >=20 > 1) for a particular globalView element, all of the referenced > sceneView elements must be of a single media type. > In this case, a consumer should choose one globalView element > of each type. >=20 > 2) each globalView element may reference sceneView elements of > multiple media types. Presumably in this case the chosen > sceneView elements of differing types have been chosen to > work well together. Presumably a consumer should choose > a single globalView element. >=20 > We already made a similar choice when we decided to restrict the > elements of a sceneView to a single type. If we want to be consistent > with that, then we should choose (1) above. [Duckworth, Mark] (1) is already chosen and documented, I don't see a need = to change it. > The tradeoffs are: >=20 > For (1): > - the assumption is that the choice of views for different media > types are independent - any audio will work equally well with > any video. This may not be true. >=20 > For (2): > - this is (arguably) easier for the consumer. It need only > search for a single globalView that it can render. And > when it chooses one, it can assume that it is a well tuned > combination of the different media types. >=20 > - if media of different types *are* independent, then it will > take more globalView elements to describe all the combinations > than (1) does. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Oct 20 11:22:02 2014 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 55AE21A8A7E for ; Mon, 20 Oct 2014 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 dhevCBdyRkzo for ; Mon, 20 Oct 2014 11:21:58 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DFD51A7010 for ; Mon, 20 Oct 2014 11:21:58 -0700 (PDT) Received: from [216.82.254.20:61850] by server-10.bemta-7.messagelabs.com id 7B/9B-15477-5C255445; Mon, 20 Oct 2014 18:21:57 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1413829315!12390035!7 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29280 invoked from network); 20 Oct 2014 18:21:57 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 20 Oct 2014 18:21:57 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 20 Oct 2014 11:20:33 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 20 Oct 2014 11:20:18 -0700 Thread-Topic: CLUE-capable vs CLUE-enabled - was RE: [clue] Updates in framework-17 Thread-Index: Ac/ska0Uy2Gcgjt+Q+eCyf4mYPpDNg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97766@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/v1DTIUbk_9NHtFKNa7zqQB9h6iU Subject: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17 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, 20 Oct 2014 18:22:00 -0000 Hi Paul, Thanks for the suggestions. Comments below. ... snip=20 > >> Media Consumer: a CLUE-capable device that that is capable of > >> receiving Capture Encodings > >> > >> Media Provider: a CLUE-capable device that is capable of sending > >> Capture Encodings > >> > >> I wonder if these defs should say "a CLUE-enabled* device. > > > > [Duckworth, Mark] We don't have a definition for "CLUE-enabled device". > Would that be "a CLUE-capable device in a CLUE-enabled call"? >=20 > ISTM the following are different states a *device* may be in: >=20 > - is entirely clueless. It hasn't included the clue feature tag or > the clue group. This is already defined as a Non-CLUE device. >=20 > - it is aware of clue, but is unable or unwilling to use CLUE right now. > It has included the clue feature tag, but not the clue group. Or else > it has included the clue group but not included any SCTP m-line in > the clue group. Perhaps this could be called CLUE-aware but > CLUE-disabled. >=20 > - it is aware of clue, and wishes to use it. It has included the clue > feature tag, and the clue group, and has included an SCTP m-line > in the clue group. Perhaps we can call this a CLUE-enabled device. > (This doesn't mean the *call* is CLUE-enabled.) >=20 > Note that this is distinct from the state of the call. You can have a > clue-enabled *device* yet not have a clue-enabled *call* - both ends > must be clue-enabled before the call is. [Duckworth, Mark] These definitions make sense, but seems to me they get to= o much into signaling detail for the framework document. I still like the = definitions of MC and MP given above. Do you think a change is really nece= ssary? If so, how about something like "a CLUE-capable device that intends= to receive Capture Encodings"?=20 Mark From nobody Mon Oct 20 11:41:41 2014 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 8C9471A903C for ; Mon, 20 Oct 2014 11:41:38 -0700 (PDT) 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 WKol4baFqXqi for ; Mon, 20 Oct 2014 11:41:36 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACF991A9030 for ; Mon, 20 Oct 2014 11:41:36 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-12v.sys.comcast.net with comcast id 5Wcu1p0044xDoy801Whclx; Mon, 20 Oct 2014 18:41:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id 5Whb1p0093Ge9ey01WhbsC; Mon, 20 Oct 2014 18:41:35 +0000 Message-ID: <5445575F.1070501@alum.mit.edu> Date: Mon, 20 Oct 2014 14:41:35 -0400 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 References: <20141018211619.25932.62629.idtracker@ietfa.amsl.com> In-Reply-To: <20141018211619.25932.62629.idtracker@ietfa.amsl.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=1413830496; bh=N0to1KyguhpPAaS1l8QPIoyIHH8lj6CFxD94K+fzG1Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DeF/ma0Cpcvmh2y5bBjpqVIb81mdby3lIwpubtWUo367Mq6rk3qzCHnla7O2AjHbg mHEr//ufkzqVu64uZeHySSUa4vD6xg1CZIFB0GKNzAksJFkaIGORjkmWMXL2S/pe6X h6YhGd/C/2/NfWtb4/ANgu3iaBULuyl8m0VN17yPiAnPuGLiEhwFGzwzEltQ8Xk+ZD +tMIcv3arO5GOkcf4R1tYO2bBujmlwI8yttU6WUBElVB6utkPe9gKuiLZd93nfcHhw St0nKQ2tifwygP+l85u/L8/4//rZ4boGWTpByM5pHTTXfxKC6CDcUWUFcyu93pR9oV +b7joc4KHm2QQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yx4Ipk8QuRy4nz4zuqVm4ahM9dQ Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:41:38 -0000 In prep for the design team call tomorrow I have a few comments on the -03 version: * Section 1: Intro With regards to the media (audio and video), systems that support I think you had better also include real-time text in the above. * Section 4.1: The solution needs to also support the simulcast case where more than one RTP session may be advertised for a Media Capture. Support of such simulcast is out of scope for CLUE but a solution is needed. Why does this say that simulcast is out of scope. We have mechanisms by which a consumer can explicitly request simulcast. Do you mean that there are some simulcast mechanisms that are out of scope? Exactly what requires a solution? And is it needed for CLUE, or more generally? * Section 4.2: Media-4: It must be possible for an original source to move among multi-content captures (i.e. at one time be sent for one MCC, and at a later time be sent for another one). I don't see a requirement that the same original to be included in multiple MCCs at the same time, or to be in a configured MCC and also to be configured on its own. Media-7: It must be possible for a receiver to identify the original capture(s) that are currently being mapped to an MCC, and correlate it with both the Clue advertisement and out-of-band (non-Clue) information such as rosters. I guess this can only be a requirement when the currently mapped source is one of the sources listed in the MCC declaration, and only for switched captures, not mixed ones. * Section 4.4: Dynamic Mapping I think there should be some discussion of how often the mid needs to be included in the RTP packets. IIUC it is not needed in all packets, so the cost is not too high. * Section 4.5: Recommendations This could be clearer. I think a receiver SHOULD support BUNDLE, and if so MUST support *receiving* mid in RTP and RTCP, and using it to map packets to m-lines. A sender SHOULD support BUNDLE, and MUST use mid if bundling m-lines that require mid to be unambiguously associate packets to m-lines. Thanks, Paul On 10/18/14 5:16 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Mapping RTP streams to CLUE media captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-03.txt > Pages : 15 > Date : 2014-10-18 > > Abstract: > This document describes how the Real Time transport Protocol (RTP) is > used in the context of the CLUE protocol. It also describes the > mechanisms and recommended practice for mapping RTP media streams > defined in SDP to CLUE media captures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Oct 21 02:18:19 2014 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 DAB4F1A00B2 for ; Tue, 21 Oct 2014 02:18:16 -0700 (PDT) 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 go8gW6ql3Yy8 for ; Tue, 21 Oct 2014 02:18:14 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD291A0149 for ; Tue, 21 Oct 2014 02:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4052; q=dns/txt; s=iport; t=1413883094; x=1415092694; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LnxoJIOe8ch4C0j84AidgOokyuO9Sc2YIpOLKSLO1DI=; b=Y0W4mOhxh8HwuyHLvHQEGref8yt2GKjHE8cgeHCtC76wO4honYS0Qtw4 9ak3T0jqFTkET+zuQZVKH62IDLN5ikuFfzdXvwMpKsUUDuwCDr1IM+lCZ eUfUvZKY0aKQGQCKLvL6+Ey4tNl0id3L0jUWuEGU1cJrXGNhOq1l3jycJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAMQjRlStJA2E/2dsb2JhbABcDoMAU1gEzAwKh00CgQ8WAX2EAgEBAQQBAQE3NBcEAgEIEQQBAQsUCQcnCxQJCAEBBAESCIg3DcNJAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQIDgGgyeBHgWSAaF7gzdAbIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,760,1406592000"; d="scan'208";a="88921052" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 21 Oct 2014 09:18:13 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s9L9IDUu010686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Oct 2014 09:18:13 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.151]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 21 Oct 2014 04:18:13 -0500 From: "Robert Hansen (rohanse2)" To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17 Thread-Index: Ac/ska0Uy2Gcgjt+Q+eCyf4mYPpDNgAfWKNg Date: Tue, 21 Oct 2014 09:18:12 +0000 Message-ID: References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97766@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97766@CRPMBOXPRD08.polycom.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/340AxHVQ3peBusjPCuvDyFQvB58 Subject: Re: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17 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, 21 Oct 2014 09:18:17 -0000 The definitions I wrote for the signalling document are: CLUE data channel: A reliable, bidirectional, transport mechanism used to convey CLUE messages. See [I-D.ietf-clue-datachannel] for more details. CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.presta-clue-protocol] and the principles of CLUE negotiation, and wishes to upgrade the call to CLUE-enabled status. CLUE-enabled call: A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP. A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled media; negotiation of the data channel and of the CLUE protocol must complete first. Calls between two CLUE-capable devices which have not yet successfully completed negotiation of support for the CLUE data channel in SDP are not considered CLUE- enabled. Non-CLUE device: A device that supports standard SIP and SDP, but either does not support CLUE, or that does but does not currently wish to invoke CLUE capabilities. CLUE-controlled media: A media "m" line that is under CLUE control; the capture source that provides the media on this "m" line is negotiated in CLUE. See Section 4 for details of how this control is signalled in SDP. There is a corresponding "non-CLUE- controlled" media term. While these are written in a fairly signalling specific matter, CLUE-capabl= e device and CLUE-enabled call could potentially be broken out for the fram= ework doc, and the signalling document could then include the signalling sp= ecific aspects of what they mean. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 20 October 2014 19:20 To: Paul Kyzivat; clue@ietf.org Subject: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework= -17 Hi Paul, Thanks for the suggestions. Comments below. ... snip=20 > >> Media Consumer: a CLUE-capable device that that is capable of > >> receiving Capture Encodings > >> > >> Media Provider: a CLUE-capable device that is capable of sending > >> Capture Encodings > >> > >> I wonder if these defs should say "a CLUE-enabled* device. > > > > [Duckworth, Mark] We don't have a definition for "CLUE-enabled device". > Would that be "a CLUE-capable device in a CLUE-enabled call"? >=20 > ISTM the following are different states a *device* may be in: >=20 > - is entirely clueless. It hasn't included the clue feature tag or > the clue group. This is already defined as a Non-CLUE device. >=20 > - it is aware of clue, but is unable or unwilling to use CLUE right now. > It has included the clue feature tag, but not the clue group. Or else > it has included the clue group but not included any SCTP m-line in > the clue group. Perhaps this could be called CLUE-aware but > CLUE-disabled. >=20 > - it is aware of clue, and wishes to use it. It has included the clue > feature tag, and the clue group, and has included an SCTP m-line > in the clue group. Perhaps we can call this a CLUE-enabled device. > (This doesn't mean the *call* is CLUE-enabled.) >=20 > Note that this is distinct from the state of the call. You can have a=20 > clue-enabled *device* yet not have a clue-enabled *call* - both ends=20 > must be clue-enabled before the call is. [Duckworth, Mark] These definitions make sense, but seems to me they get to= o much into signaling detail for the framework document. I still like the = definitions of MC and MP given above. Do you think a change is really nece= ssary? If so, how about something like "a CLUE-capable device that intends= to receive Capture Encodings"?=20 Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Tue Oct 21 07:25:39 2014 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 A49E51A6F68 for ; Tue, 21 Oct 2014 07:25:31 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 prp4zPvev10x for ; Tue, 21 Oct 2014 07:25:28 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.6]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA451A6FE4 for ; Tue, 21 Oct 2014 07:24:35 -0700 (PDT) Received: from [216.82.249.212:13828] by server-6.bemta-12.messagelabs.com id 9A/1B-11230-2AC66445; Tue, 21 Oct 2014 14:24:34 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-219.messagelabs.com!1413901471!12261859!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14489 invoked from network); 21 Oct 2014 14:24:31 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2014 14:24:31 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 21 Oct 2014 07:24:30 -0700 From: "Duckworth, Mark" To: "Robert Hansen (rohanse2)" , Paul Kyzivat , "clue@ietf.org" Date: Tue, 21 Oct 2014 07:24:28 -0700 Thread-Topic: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17 Thread-Index: Ac/ska0Uy2Gcgjt+Q+eCyf4mYPpDNgAfWKNgAAqyOpA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97820@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97766@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Hlm421b3szlFw_p__3-SFZnrGxM Subject: Re: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in framework-17 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, 21 Oct 2014 14:25:31 -0000 Hi Rob, The definitions for CLUE-capable device and CLUE-enabled call are already i= n the framework (as Paul suggested a while ago), identical to the definitio= ns in signaling document. I think those are high level enough for the fram= ework, and nobody has objected to those definitions in the framework. I was questioning Paul's suggestion of new definitions for CLUE-aware devic= e, CLUE-disabled device, CLUE-enabled device. Maybe these would be useful = in the signaling document, but I think they are not needed for the framewor= k. Mark > -----Original Message----- > From: Robert Hansen (rohanse2) [mailto:rohanse2@cisco.com] > Sent: Tuesday, October 21, 2014 5:18 AM > To: Duckworth, Mark; Paul Kyzivat; clue@ietf.org > Subject: RE: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in > framework-17 >=20 > The definitions I wrote for the signalling document are: >=20 > CLUE data channel: A reliable, bidirectional, transport mechanism > used to convey CLUE messages. See [I-D.ietf-clue-datachannel] for > more details. >=20 > CLUE-capable device: A device that supports the CLUE data channel > [I-D.ietf-clue-datachannel], the CLUE protocol > [I-D.presta-clue-protocol] and the principles of CLUE negotiation, > and wishes to upgrade the call to CLUE-enabled status. >=20 > CLUE-enabled call: A call in which two CLUE-capable devices have > successfully negotiated support for a CLUE data channel in SDP. A > CLUE-enabled call is not necessarily immediately able to send > CLUE-controlled media; negotiation of the data channel and of the > CLUE protocol must complete first. Calls between two CLUE-capable > devices which have not yet successfully completed negotiation of > support for the CLUE data channel in SDP are not considered CLUE- > enabled. >=20 > Non-CLUE device: A device that supports standard SIP and SDP, but > either does not support CLUE, or that does but does not currently > wish to invoke CLUE capabilities. >=20 > CLUE-controlled media: A media "m" line that is under CLUE control; > the capture source that provides the media on this "m" line is > negotiated in CLUE. See Section 4 for details of how this control > is signalled in SDP. There is a corresponding "non-CLUE- > controlled" media term. >=20 > While these are written in a fairly signalling specific matter, CLUE-capa= ble > device and CLUE-enabled call could potentially be broken out for the > framework doc, and the signalling document could then include the signall= ing > specific aspects of what they mean. >=20 > Rob >=20 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: 20 October 2014 19:20 > To: Paul Kyzivat; clue@ietf.org > Subject: [clue] CLUE-capable vs CLUE-enabled - was RE: Updates in > framework-17 >=20 > Hi Paul, >=20 > Thanks for the suggestions. Comments below. >=20 > ... snip > > >> Media Consumer: a CLUE-capable device that that is capable of > > >> receiving Capture Encodings > > >> > > >> Media Provider: a CLUE-capable device that is capable of sendin= g > > >> Capture Encodings > > >> > > >> I wonder if these defs should say "a CLUE-enabled* device. > > > > > > [Duckworth, Mark] We don't have a definition for "CLUE-enabled > device". > > Would that be "a CLUE-capable device in a CLUE-enabled call"? > > > > ISTM the following are different states a *device* may be in: > > > > - is entirely clueless. It hasn't included the clue feature tag or > > the clue group. This is already defined as a Non-CLUE device. > > > > - it is aware of clue, but is unable or unwilling to use CLUE right now= . > > It has included the clue feature tag, but not the clue group. Or els= e > > it has included the clue group but not included any SCTP m-line in > > the clue group. Perhaps this could be called CLUE-aware but > > CLUE-disabled. > > > > - it is aware of clue, and wishes to use it. It has included the clue > > feature tag, and the clue group, and has included an SCTP m-line > > in the clue group. Perhaps we can call this a CLUE-enabled device. > > (This doesn't mean the *call* is CLUE-enabled.) > > > > Note that this is distinct from the state of the call. You can have a > > clue-enabled *device* yet not have a clue-enabled *call* - both ends > > must be clue-enabled before the call is. >=20 > [Duckworth, Mark] These definitions make sense, but seems to me they get > too much into signaling detail for the framework document. I still like = the > definitions of MC and MP given above. Do you think a change is really > necessary? If so, how about something like "a CLUE-capable device that > intends to receive Capture Encodings"? >=20 > Mark >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Oct 21 07:42:47 2014 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 EF0D71A86E5 for ; Tue, 21 Oct 2014 07:42:45 -0700 (PDT) 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 eAGrtGVyzlnP for ; Tue, 21 Oct 2014 07:42:44 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08B81A8028 for ; Tue, 21 Oct 2014 07:41:57 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-07v.sys.comcast.net with comcast id 5qgb1p00358ss0Y01qhx0w; Tue, 21 Oct 2014 14:41:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 5qhw1p00W3Ge9ey01qhxa2; Tue, 21 Oct 2014 14:41:57 +0000 Message-ID: <544670B4.4080805@alum.mit.edu> Date: Tue, 21 Oct 2014 10:41:56 -0400 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 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=1413902517; bh=dq6Rz0HiR1UH6Hj67Wga0rpM+M5PO6R+k/hk0cNY1vA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BM2hYhlJI2E8MlAJFcOYLNg8IiZ6CaBMxFJZTtZ1eIRWQkd0gi5x11DwsUz/mPNnM z2iG/eBOHNzEQyqpLcee+aQWzvK3IIpUycUzb3gCHKwv+tXStovSvKr4EqHizK7MaB OcL6GeIDdYU/dxu928RT1TV48f5k6Y7Z3izVrLAKXfdTX19FemYjtg5vSfLnltJded 5B54jVvWXOdG8aeyLNacu09dd10il6y1/NwTqlwjZa7DdrdRq0zw6r+InnXy8FX3pw USmKsepYKrXV6fyziLo4HxIT+8OB4WrVa/EzwkVE6x9ufbVGuqeNmSUTy/qqE+JGpn JMavi3YMD/J7A== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xxhli99nUmY58JmOO1nU8i1uvrI Subject: [clue] Minutes & Action Items from today's design team meeting: 21-oct-2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 14:42:46 -0000 I posted the minutes from today's design team call to the clue wiki: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-141021.txt I didn't do a great job of minute taking. Please take a look and if necessary send me corrections. Especially check the action items: * Roni: write a proposal to the mailing list regarding what to do about simulcast. * Jonathan: write a proposal for how long to send capture-id in RTP/RTCP. * Rob: update signaling draft to discuss MCCs that have sources not listed in MCC description. I am not confident that I have captured them accurately. (I'm not even sure that Rob's action item is properly an action on the signaling draft.) Thanks, Paul From nobody Tue Oct 21 08:41:48 2014 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 E75051A87EA for ; Tue, 21 Oct 2014 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 DOkr3m3fCfit for ; Tue, 21 Oct 2014 08:41:44 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.100]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC4C1A8848 for ; Tue, 21 Oct 2014 08:41:21 -0700 (PDT) Received: from [216.82.254.20:57865] by server-4.bemta-7.messagelabs.com id 29/23-28388-0AE76445; Tue, 21 Oct 2014 15:41:20 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-47.messagelabs.com!1413906077!12728347!8 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26866 invoked from network); 21 Oct 2014 15:41:20 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-13.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2014 15:41:20 -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; Tue, 21 Oct 2014 08:38:49 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 21 Oct 2014 08:38:48 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Tue, 21 Oct 2014 08:38:32 -0700 Thread-Topic: [clue] Minutes & Action Items from today's design team meeting: 21-oct-2014 Thread-Index: Ac/tPUlDHLdIhEADS22NTSeXjKuQVQABnaow Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA97845@CRPMBOXPRD08.polycom.com> References: <544670B4.4080805@alum.mit.edu> In-Reply-To: <544670B4.4080805@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: http://mailarchive.ietf.org/arch/msg/clue/e8x3hhpdsxlRD5nEG-5yVJthGqI Subject: Re: [clue] Minutes & Action Items from today's design team meeting: 21-oct-2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 15:41:46 -0000 Hi Paul, Your notes are consistent with my memory of the meeting. Additionally, Rob= 's action to discuss MCCs with sources not in the MCC description was at le= ast in part motivated by a use case Jonathan mentioned: An MCU provider is sending an MCC (which includes listed individual capture= s, and meant to include current talker). Then a new endpoint joins, and quickly becomes the current talker. The MCU can include media captures from the new endpoint in the existing MC= C, even before it has a chance to update its advertisement and get a new co= nfigure message from the consumer. Regarding this part of the minutes: Jonathan: is it possible to have both named and unnamed captures? If so, ne= ed to do some work in the draft about it. Others: [didn't catch what was said. I think the general sense was "don't k= now".] That was regarding the captures that contribute to an MCC. As I recall, we= said the advertisement can't express it that way, with both named and unna= med captures as contributors to an MCC (according to framework and data mod= el). But race conditions like mentioned above can happen, which led to Rob= 's action item. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, October 21, 2014 10:42 AM > To: CLUE > Subject: [clue] Minutes & Action Items from today's design team meeting: > 21-oct-2014 >=20 > I posted the minutes from today's design team call to the clue wiki: >=20 > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design- > Team/minutes-141021.txt >=20 > I didn't do a great job of minute taking. Please take a look and if > necessary send me corrections. >=20 > Especially check the action items: >=20 > * Roni: write a proposal to the mailing list regarding what to > do about simulcast. >=20 > * Jonathan: write a proposal for how long to send capture-id > in RTP/RTCP. >=20 > * Rob: update signaling draft to discuss MCCs that have sources > not listed in MCC description. >=20 > I am not confident that I have captured them accurately. (I'm not even > sure that Rob's action item is properly an action on the signaling draft.= ) >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Oct 21 14:01:07 2014 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 167061A802D for ; Tue, 21 Oct 2014 14:01:06 -0700 (PDT) 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_20=-0.001, 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 Hq4t0VOa3gDa for ; Tue, 21 Oct 2014 14:01:03 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC511A8701 for ; Tue, 21 Oct 2014 14:00:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id em10so2934914wid.7 for ; Tue, 21 Oct 2014 14:00:53 -0700 (PDT) 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=AxHxe6QPW9/AXKoPxdDB5x/e4/vJ3hpKhaA8/QRDGwQ=; b=kcWzlu8wSl0vp0f+GzQv0JTgprTBtLOnqXeXkzsKxMuEF1O0rQ8xhRWALULVj0hyBj fRpqycG6sUP/Dj0vnK7C3ULsyOOO+FhWDHGkHNi64L63y5o7Jlu+yZdGI4BXhV/Y/YAZ 2Axv1tP1NIpsTxBiKZ5CQpXKk3X+ijwsC6h6Me+C43CXUsFO+Mfpn39wqjNWKoxZdSq0 rq3a/9gl6bhKBoo/EmqqWJyIXkcdTEg0txIobEsD336Jek1sciMMXbqkqo9gBbJDL2f/ 1ansdyM/PVVZCAFgH07EgATW9lLPFLluSoY1+cFp2xpjBMM1fbzcwZbCqPFuuU2MVXyb bqkA== X-Received: by 10.180.104.7 with SMTP id ga7mr731606wib.1.1413925252904; Tue, 21 Oct 2014 14:00:52 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id u4sm130175wiy.9.2014.10.21.14.00.51 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Oct 2014 14:00:52 -0700 (PDT) From: "Roni Even" To: Date: Wed, 22 Oct 2014 00:00:48 +0300 Message-ID: <034b01cfed72$18953500$49bf9f00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_034C_01CFED8B.3DE33050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/taerSE4jZUcK8SdO0mSUZD2VGvQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t0arHVV09W5XpQIcZ4uIc2SNCw8 Subject: [clue] CLUE and Simulcast - ticket #47 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, 21 Oct 2014 21:01:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_034C_01CFED8B.3DE33050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, During our weekly design team meeting we discussed simulcast support in CLUE. Here is my take on the options, my description may not be accurate and the purpose here is to continue the discussion allowing us to have a better view of the options. Looking at the state of simulcast support in other WGs, there is an individual draft http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04 that being discussed. The proposed solution is based on the unified plan where all encoded streams composing alternatives of a simulcast stream are in the same m-line. The alternatives are described using an SDP media level attribute "a=simulcast". This attribute is not defined for SDP session level. The first question we had is if we should base CLUE simulcast support on this individual draft based on CLUE timeline or try to define a different multicast solution at the CLUE protocol level. If we base our solution on the avtcore-rtp-simulcast-04 document the advertisement will include an individual encoding that will relate to optional multiple simulcast encoding and the configure will select such encoding. The actual number of different stream that will compose the simulcast stream will be negotiated using Offer/Answer as described in the above document. The risk here is that this is an individual draft and we may need to review the CLUE support if it changes. The advantage is that we will have simulcast the same for CLUE and non-CLUE systems. The other option for simulcast support in the CLUE protocol can be based on having separate Media Capture for each of the different simulcast encoding and use MCC to compose the simulcast alternatives. We will need some way to escribe that this MCC is for simulcast description and to provide the actual allowed individual encodes combinations for the Configuration by the consumer. Thanks Roni ------=_NextPart_000_034C_01CFED8B.3DE33050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

During our = weekly design team meeting we discussed simulcast support in CLUE.  =

 

Here is my take on the options, my description may not = be accurate and the purpose here is to continue the discussion allowing = us to have a better view of the options.

 

Looking at = the state of simulcast support in other WGs, there is an individual = draft http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04= that being discussed. The proposed solution is based on the unified = plan where all encoded streams composing alternatives of a simulcast = stream are in the same m-line.   The alternatives are = described using an SDP media level attribute = “a=3Dsimulcast”. This attribute is not defined for SDP = session level.

 

The first = question we had is if we should base CLUE simulcast support on this = individual draft based on CLUE timeline or try to define a different = multicast solution at the CLUE protocol level.

 

 

If we base = our solution on the avtcore-rtp-simulcast-04 document the advertisement = will include an individual encoding that will relate to optional = multiple simulcast encoding and the configure will select such encoding. = The actual number of different stream that will compose the simulcast = stream will be negotiated using Offer/Answer as described in the above = document. The risk here is that this is an individual draft and we may = need to review the CLUE support if it changes. The advantage is that we = will have simulcast the same for CLUE and non-CLUE = systems.

 

 

The other = option for simulcast support in the CLUE protocol can be based on having = separate Media Capture for each of the different simulcast encoding and = use MCC to compose the simulcast alternatives. We will need some way to = escribe that this MCC is for simulcast description and to provide the = actual allowed individual encodes combinations for the Configuration by = the consumer.

 

 

Thanks

Roni

 

------=_NextPart_000_034C_01CFED8B.3DE33050-- From nobody Tue Oct 21 15:00:38 2014 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 878121A8799 for ; Tue, 21 Oct 2014 15:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Gx3CGJfuDZmv for ; Tue, 21 Oct 2014 15:00:34 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F731A8751 for ; Tue, 21 Oct 2014 15:00:34 -0700 (PDT) Received: from [216.82.254.20:15260] by server-9.bemta-7.messagelabs.com id 41/FF-03013-187D6445; Tue, 21 Oct 2014 22:00:33 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1413928831!12721984!6 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3505 invoked from network); 21 Oct 2014 22:00:33 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 21 Oct 2014 22:00:33 -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; Tue, 21 Oct 2014 14:57:01 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 21 Oct 2014 14:57:01 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 21 Oct 2014 14:56:43 -0700 Thread-Topic: diagram for Global View List Thread-Index: Ac/teXYS4k//d6TSSvqdobbnfQJtdA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@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_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790ACRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2u9psSKtYEoGBby7xR9NWPQzVEw Subject: [clue] diagram for Global View List 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, 21 Oct 2014 22:00:36 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790ACRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is my attempt at a diagram to depict Global Views in a Global View Lis= t. Should I add this to the framework document? Any comments? Mark ........................................................ . Advertisement . . . . +--------------+ +-------------------------+ . . |Scene 1 | |Global View List | . . | | | | . . | CSV1 (v)<----------------- Global View (csv 1) | . . | <-------. | | . . | | *--------- Global View (csv 1,5) | . . | CSV2 (v) | | | | . . | | | | | . . | CSV3 (v)<---------*------- Global View (csv 3,5) | . . | | | | | | . . | CSV4 (a)<----------------- Global View (csv 4) | . . | <-----------. | | . . +--------------+ | | *----- Global View (csv 4,6) | . . | | | | | . . +--------------+ | | | +-------------------------+ . . |Scene 2 | | | | . . | | | | | . . | CSV5 (v)<-------' | | . . | <---------' | . . | | | (v) =3D video . . | CSV6 (a)<-----------' (a) =3D audio . . | | . . +--------------+ . `......................................................' --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790ACRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is my attempt at a diagram to depict Gl= obal Views in a Global View List.  Should I add this to the framework = document?  Any comments?

=  

Mark

   ........................................= ................

   . Advertisement  &nbs= p;            &= nbsp;           &nbs= p;            .=

   .         = ;            &n= bsp;            = ;            &n= bsp;       .

   . +----= ----------+         +--------------= -----------+ .

   . |Scene 1    &= nbsp;  |         |Global View = List         | .<= /p>

 =   . |           = ;   |         | &nbs= p;            &= nbsp;          | .<= /span>

   . | CSV1 (v)<----------------- Global View (csv 1) &n= bsp; | .

   . |      &n= bsp;  <-------.      |   &n= bsp;            = ;         | .

=

 &nb= sp; . |           &n= bsp;  |  *--------- Global View (csv 1,5) | .

 &= nbsp; . | CSV2 (v)     |  |    = ;  |           =             &nb= sp; | .

   . |      &nb= sp;       |  |    &n= bsp; |            &n= bsp;            = ;| .

   . | CSV3 (v)<---------*------- Global View= (csv 3,5) | .

   . |     &n= bsp;        |  | |   = ; |            =              | = .

   . | CSV4 (a)<----------------- Global View (c= sv 4)   | .

   . |    &= nbsp;    <-----------.  |    &nb= sp;             = ;       | .

   . += --------------+  | | *----- Global View (csv 4,6) | .

&nbs= p;  .           = ;        | | |  |   =             &nb= sp;         | .

 &= nbsp; . +--------------+  | | |  +-------------------------+ .

   . |Scene 2       |&nbs= p; | | |           &= nbsp;           &nbs= p;      .

   . |  =             |  = | | |           &nbs= p;            &= nbsp;     .

   . | CSV5 (v)<--= -----' | |           = ;            &n= bsp;      .

   . | &nbs= p;       <---------' |   &n= bsp;            = ;            &n= bsp; .

   . |      &nbs= p;       |      |&nb= sp;       (v) =3D video   &nbs= p;       .

   . | CSV6 = (a)<-----------'        (a) =3D audio=            .

=    . |          = ;    |         =             &nb= sp;            =    .

   . +--------------+   = ;            &n= bsp;            = ;         .

  = ; `......................................................'

 

 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790ACRPMBOXPRD08p_-- From nobody Wed Oct 22 07:41:28 2014 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 38A201ACCFA for ; Wed, 22 Oct 2014 07:41:25 -0700 (PDT) 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 duyRYlTdpJd9 for ; Wed, 22 Oct 2014 07:41:23 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57ED51ACCF9 for ; Wed, 22 Oct 2014 07:41:22 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so2974227lbv.10 for ; Wed, 22 Oct 2014 07:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TTe/eWEioFODG0xVt+I16Diful7lsiNAc+NAprtKnvk=; b=YCBI4rjbUSmvu44YXPhglkhtkr1tQKHgLDrrMdm6VjOgHbeTrfxS8ZRTXxDgHJI4Qh msTmEcHXK8MyFYYHynv6nnlYrZEwvQy4CsAmJwY1ePOgnInT6xsKD2US2/JN22ZF+axO 6K4SfIbZtzyDayUiuYEAtFd9pPHmxX8hJCEckJgtIibJ653Ep3KVTuQJBcch1MO7d2Kb /7lCYfHx6gjzMvqx7zauokxSeo90jTMj72KZC9PbwxmXiIXwYDpXfwi8uhBNKDMIii97 qV0+dT+OrIo9de/vkWWnQi8D3OlRDwMDoS05BFQ3W+IXMlQ9yNX+DtQXKluB4QnJYyOU oMeQ== MIME-Version: 1.0 X-Received: by 10.152.36.230 with SMTP id t6mr3370588laj.88.1413988880163; Wed, 22 Oct 2014 07:41:20 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Wed, 22 Oct 2014 07:41:20 -0700 (PDT) In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@CRPMBOXPRD08.polycom.com> Date: Wed, 22 Oct 2014 09:41:20 -0500 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=089e0160c0dceb26fc050603f071 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2-b9x0Iege2Rfgy61S0tTSoszwM Cc: "clue@ietf.org" Subject: Re: [clue] diagram for Global View List 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, 22 Oct 2014 14:41:25 -0000 --089e0160c0dceb26fc050603f071 Content-Type: text/plain; charset=UTF-8 The diagram doesn't display well with my emailer. Would you mind uploading the .txt file to the wiki? You could just upload the file and provide a link without adding any other text to the wiki or you could send to me and I'll upload. I'm sure I will like it since I think diagrams are extremely helpful in these documents. Thanks, Mary On Tue, Oct 21, 2014 at 4:56 PM, Duckworth, Mark wrote: > Here is my attempt at a diagram to depict Global Views in a Global View > List. Should I add this to the framework document? Any comments? > > > > Mark > > > > ........................................................ > > . Advertisement . > > . . > > . +--------------+ +-------------------------+ . > > . |Scene 1 | |Global View List | . > > . | | | | . > > . | CSV1 (v)<----------------- Global View (csv 1) | . > > . | <-------. | | . > > . | | *--------- Global View (csv 1,5) | . > > . | CSV2 (v) | | | | . > > . | | | | | . > > . | CSV3 (v)<---------*------- Global View (csv 3,5) | . > > . | | | | | | . > > . | CSV4 (a)<----------------- Global View (csv 4) | . > > . | <-----------. | | . > > . +--------------+ | | *----- Global View (csv 4,6) | . > > . | | | | | . > > . +--------------+ | | | +-------------------------+ . > > . |Scene 2 | | | | . > > . | | | | | . > > . | CSV5 (v)<-------' | | . > > . | <---------' | . > > . | | | (v) = video . > > . | CSV6 (a)<-----------' (a) = audio . > > . | | . > > . +--------------+ . > > `......................................................' > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --089e0160c0dceb26fc050603f071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+VGhlIGRpYWdyYW0gZG9lc24mIzM5O3QgZGlzcGxheSB3ZWxsIHdpdGgg bXkgZW1haWxlci7CoCBXb3VsZCB5b3UgbWluZCB1cGxvYWRpbmcgdGhlIC50eHQgZmlsZSB0byB0 aGUgd2lraT/CoCBZb3UgY291bGQganVzdCB1cGxvYWQgdGhlIGZpbGUgYW5kIHByb3ZpZGUgYSBs aW5rIHdpdGhvdXQgYWRkaW5nIGFueSBvdGhlciB0ZXh0IHRvIHRoZSB3aWtpIG9yIHlvdSBjb3Vs ZCBzZW5kIHRvIG1lIGFuZCBJJiMzOTtsbCB1cGxvYWQuIMKgPGRpdj48YnI+PC9kaXY+PGRpdj5J JiMzOTttIHN1cmUgSSB3aWxsIGxpa2UgaXQgc2luY2UgSSB0aGluayBkaWFncmFtcyBhcmUgZXh0 cmVtZWx5IGhlbHBmdWwgaW4gdGhlc2UgZG9jdW1lbnRzLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhhbmtzLDwvZGl2PjxkaXY+TWFyeTwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4 dHJhIj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgT2N0IDIxLCAyMDE0IGF0 IDQ6NTYgUE0sIER1Y2t3b3J0aCwgTWFyayA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhyZWY9Im1h aWx0bzpNYXJrLkR1Y2t3b3J0aEBwb2x5Y29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1hcmsuRHVj a3dvcnRoQHBvbHljb20uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj48ZGl2PjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+SGVyZSBpcyBteSBhdHRlbXB0IGF0IGEgZGlhZ3JhbSB0byBk ZXBpY3QgR2xvYmFsIFZpZXdzIGluIGEgR2xvYmFsIFZpZXcgTGlzdC7CoCBTaG91bGQgSSBhZGQg dGhpcyB0byB0aGUgZnJhbWV3b3JrIGRvY3VtZW50P8KgIEFueSBjb21tZW50cz88dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48dT48L3U+wqA8dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk1hcms8dT48L3U+PHU+PC91Pjwvc3Bh bj48L3A+PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48dT48L3U+wqA8dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4g QWR2ZXJ0aXNlbWVudMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAuPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ wqDCoCAuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAu PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoCAuICstLS0tLS0tLS0tLS0tLSvCoMKgwqDCoMKgwqDC oMKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w PjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDC oCAuIHxTY2VuZSAxwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHxHbG9iYWwgVmlldyBM aXN0wqDCoMKgwqDCoMKgwqDCoCB8IC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4gfMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfCAuPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ wqDCoCAuIHwgQ1NWMSAodikmbHQ7LS0tLS0tLS0tLS0tLS0tLS0gR2xvYmFsIFZpZXcgKGNzdiAx KcKgwqAgfCAuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoCAuIHzCoMKgwqDCoMKgwqDCoMKgICZs dDstLS0tLS0tLsKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCB8IC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4gfMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIHzCoCAqLS0tLS0tLS0tIEdsb2JhbCBWaWV3IChjc3YgMSw1KSB8IC48 dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4gfCBDU1YyICh2KcKgwqDCoMKgIHzCoCB8wqDCoMKg wqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwg Ljx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg fMKgIHzCoMKgwqDCoMKgIHwgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgfCAuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoCAuIHwgQ1NWMyAodikmbHQ7LS0t LS0tLS0tKi0tLS0tLS0gR2xvYmFsIFZpZXcgKGNzdiAzLDUpIHwgLjx1PjwvdT48dT48L3U+PC9z cGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPsKgwqAgLiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIHwgfMKgwqDCoCB8wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHwgLjx1PjwvdT48 dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPsKgwqAgLiB8IENTVjQgKGEpJmx0Oy0tLS0tLS0tLS0tLS0tLS0tIEdsb2Jh bCBWaWV3IChjc3YgNCnCoMKgIHwgLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLiB8wqDCoMKg wqDCoMKgwqDCoCAmbHQ7LS0tLS0tLS0tLS0uwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIMKgwqDCoMKgwqDCoMKgwqB8IC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4gKy0t LS0tLS0tLS0tLS0tK8KgIHwgfCAqLS0tLS0gR2xvYmFsIFZpZXcgKGNzdiA0LDYpIHwgLjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPsKgwqAgLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCB8IHwgfMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgfCAuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDCoCAuICstLS0tLS0tLS0tLS0tLSvCoCB8IHwg fMKgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w PjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+wqDC oCAuIHxTY2VuZSAywqDCoMKgwqDCoMKgIHzCoCB8IHwgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PsKgwqAgLiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfMKgIHwgfCB8wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAuPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+wqDCoCAuIHwgQ1NWNSAodikmbHQ7LS0tLS0tLSYjMzk7IHwgfMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgLjx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPsKgwqAgLiB8wqDCoMKgwqDCoMKgwqDCoCAmbHQ7LS0tLS0tLS0tJiMz OTsgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgfMKgwqDCoMKgwqAgfMKgwqDCoMKgwqDCoMKgICh2KSA9IHZpZGVvwqDCoMKgwqDCoMKg wqDCoMKgwqAgLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLiB8IENTVjYgKGEpJmx0Oy0tLS0t LS0tLS0tJiMzOTvCoMKgwqDCoMKgwqDCoCAoYSkgPSBhdWRpb8KgwqDCoMKgwqDCoMKgwqDCoMKg IC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIC4gfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPsKgwqAgLiArLS0tLS0tLS0t LS0tLS0rwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7CoMKgIGAuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4mIzM5Ozx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjx1PjwvdT7CoDx1PjwvdT48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHU+PC91PsKgPHU+PC91Pjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KY2x1ZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86Y2x1ZUBpZXRmLm9yZyI+Y2x1ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+PGJyPg0KPGJyPjwvYmxv Y2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQo= --089e0160c0dceb26fc050603f071-- From nobody Wed Oct 22 07:45:34 2014 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 499491ACD0E for ; Wed, 22 Oct 2014 07:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0XDRMSRM6lTg for ; Wed, 22 Oct 2014 07:45:26 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4AAF1ACD12 for ; Wed, 22 Oct 2014 07:45:07 -0700 (PDT) Received: from [216.82.254.20:32978] by server-2.bemta-7.messagelabs.com id 7C/3A-05570-3F2C7445; Wed, 22 Oct 2014 14:45:07 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1413989106!12307166!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14825 invoked from network); 22 Oct 2014 14:45:06 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 22 Oct 2014 14:45:06 -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; Wed, 22 Oct 2014 07:45:06 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Wed, 22 Oct 2014 07:45:21 -0700 From: "Duckworth, Mark" To: Mary Barnes Date: Wed, 22 Oct 2014 07:45:03 -0700 Thread-Topic: [clue] diagram for Global View List Thread-Index: Ac/uBkGDZcMmMMthSpC+RMunfSnxMQAAEdhQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AE@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@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_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AECRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gBqgY_ubjEUdlqqneutg_OtUhMs Cc: "clue@ietf.org" Subject: Re: [clue] diagram for Global View List 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, 22 Oct 2014 14:45:30 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AECRPMBOXPRD08p_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSB0cnkgdmlld2luZyBpdCBpbiB0aGUgZW1haWwgYXJjaGl2ZT8gIEl0IGxvb2tzIG9r YXkgdGhlcmUgKGluIGNocm9tZSBicm93c2VyLCBhdCBsZWFzdCkuICBMaW5lcyBhcmUgc3BhY2Vk IGEgYml0IGZhciBhcGFydCwgYnV0IGdlbmVyYWxseSBpdOKAmXMgcmVhZGFibGUuDQpodHRwOi8v d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJyZW50L21zZzA0MTkwLmh0bWwN Cg0KTWFyaw0KDQpGcm9tOiBNYXJ5IEJhcm5lcyBbbWFpbHRvOm1hcnkuaWV0Zi5iYXJuZXNAZ21h aWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDIyLCAyMDE0IDEwOjQxIEFNDQpUbzog RHVja3dvcnRoLCBNYXJrDQpDYzogY2x1ZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtjbHVlXSBk aWFncmFtIGZvciBHbG9iYWwgVmlldyBMaXN0DQoNClRoZSBkaWFncmFtIGRvZXNuJ3QgZGlzcGxh eSB3ZWxsIHdpdGggbXkgZW1haWxlci4gIFdvdWxkIHlvdSBtaW5kIHVwbG9hZGluZyB0aGUgLnR4 dCBmaWxlIHRvIHRoZSB3aWtpPyAgWW91IGNvdWxkIGp1c3QgdXBsb2FkIHRoZSBmaWxlIGFuZCBw cm92aWRlIGEgbGluayB3aXRob3V0IGFkZGluZyBhbnkgb3RoZXIgdGV4dCB0byB0aGUgd2lraSBv ciB5b3UgY291bGQgc2VuZCB0byBtZSBhbmQgSSdsbCB1cGxvYWQuDQoNCkknbSBzdXJlIEkgd2ls bCBsaWtlIGl0IHNpbmNlIEkgdGhpbmsgZGlhZ3JhbXMgYXJlIGV4dHJlbWVseSBoZWxwZnVsIGlu IHRoZXNlIGRvY3VtZW50cy4NCg0KVGhhbmtzLA0KTWFyeQ0KDQpPbiBUdWUsIE9jdCAyMSwgMjAx NCBhdCA0OjU2IFBNLCBEdWNrd29ydGgsIE1hcmsgPE1hcmsuRHVja3dvcnRoQHBvbHljb20uY29t PG1haWx0bzpNYXJrLkR1Y2t3b3J0aEBwb2x5Y29tLmNvbT4+IHdyb3RlOg0KDQpIZXJlIGlzIG15 IGF0dGVtcHQgYXQgYSBkaWFncmFtIHRvIGRlcGljdCBHbG9iYWwgVmlld3MgaW4gYSBHbG9iYWwg VmlldyBMaXN0LiAgU2hvdWxkIEkgYWRkIHRoaXMgdG8gdGhlIGZyYW1ld29yayBkb2N1bWVudD8g IEFueSBjb21tZW50cz8NCg0KDQoNCk1hcmsNCg0KDQoNCiAgIC4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uDQoNCiAgIC4gQWR2ZXJ0aXNlbWVu dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4g Ky0tLS0tLS0tLS0tLS0tKyAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAuDQoN CiAgIC4gfFNjZW5lIDEgICAgICAgfCAgICAgICAgIHxHbG9iYWwgVmlldyBMaXN0ICAgICAgICAg fCAuDQoNCiAgIC4gfCAgICAgICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgfCAuDQoNCiAgIC4gfCBDU1YxICh2KTwtLS0tLS0tLS0tLS0tLS0tLSBHbG9iYWwgVmll dyAoY3N2IDEpICAgfCAuDQoNCiAgIC4gfCAgICAgICAgIDwtLS0tLS0tLiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgfCAuDQoNCiAgIC4gfCAgICAgICAgICAgICAgfCAgKi0tLS0tLS0t LSBHbG9iYWwgVmlldyAoY3N2IDEsNSkgfCAuDQoNCiAgIC4gfCBDU1YyICh2KSAgICAgfCAgfCAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAuDQoNCiAgIC4gfCAgICAgICAgICAgICAg fCAgfCAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAuDQoNCiAgIC4gfCBDU1YzICh2 KTwtLS0tLS0tLS0qLS0tLS0tLSBHbG9iYWwgVmlldyAoY3N2IDMsNSkgfCAuDQoNCiAgIC4gfCAg ICAgICAgICAgICAgfCAgfCB8ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgfCAuDQoNCiAg IC4gfCBDU1Y0IChhKTwtLS0tLS0tLS0tLS0tLS0tLSBHbG9iYWwgVmlldyAoY3N2IDQpICAgfCAu DQoNCiAgIC4gfCAgICAgICAgIDwtLS0tLS0tLS0tLS4gIHwgICAgICAgICAgICAgICAgICAgICAg ICAgfCAuDQoNCiAgIC4gKy0tLS0tLS0tLS0tLS0tKyAgfCB8ICotLS0tLSBHbG9iYWwgVmlldyAo Y3N2IDQsNikgfCAuDQoNCiAgIC4gICAgICAgICAgICAgICAgICAgfCB8IHwgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgfCAuDQoNCiAgIC4gKy0tLS0tLS0tLS0tLS0tKyAgfCB8IHwgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAuDQoNCiAgIC4gfFNjZW5lIDIgICAgICAgfCAgfCB8IHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4gfCAgICAgICAgICAgICAgfCAg fCB8IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4gfCBDU1Y1ICh2KTwt LS0tLS0tJyB8IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4gfCAgICAg ICAgIDwtLS0tLS0tLS0nIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAuDQoNCiAgIC4g fCAgICAgICAgICAgICAgfCAgICAgIHwgICAgICAgICh2KSA9IHZpZGVvICAgICAgICAgICAuDQoN CiAgIC4gfCBDU1Y2IChhKTwtLS0tLS0tLS0tLScgICAgICAgIChhKSA9IGF1ZGlvICAgICAgICAg ICAuDQoNCiAgIC4gfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAuDQoNCiAgIC4gKy0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAuDQoNCiAgIGAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4nDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpjbHVlQGlldGYub3Jn PG1haWx0bzpjbHVlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jbHVlDQoNCg== --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AECRPMBOXPRD08p_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48 ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5DYW4geW91IHRyeSB2aWV3aW5nIGl0IGluIHRoZSBlbWFpbCBhcmNoaXZlP8KgIEl0 IGxvb2tzIG9rYXkgdGhlcmUgKGluIGNocm9tZSBicm93c2VyLCBhdCBsZWFzdCkuwqAgTGluZXMg YXJlIHNwYWNlZCBhIGJpdCBmYXIgYXBhcnQsIGJ1dCBnZW5lcmFsbHkgaXTigJlzIHJlYWRhYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvY2x1ZS9jdXJyZW50 L21zZzA0MTkwLmh0bWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk1hcms8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IE1hcnkgQmFybmVzIFttYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb21d IDxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBPY3RvYmVyIDIyLCAyMDE0IDEwOjQxIEFNPGJy PjxiPlRvOjwvYj4gRHVja3dvcnRoLCBNYXJrPGJyPjxiPkNjOjwvYj4gY2x1ZUBpZXRmLm9yZzxi cj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtjbHVlXSBkaWFncmFtIGZvciBHbG9iYWwgVmlldyBMaXN0 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGUgZGlhZ3JhbSBkb2Vz bid0IGRpc3BsYXkgd2VsbCB3aXRoIG15IGVtYWlsZXIuJm5ic3A7IFdvdWxkIHlvdSBtaW5kIHVw bG9hZGluZyB0aGUgLnR4dCBmaWxlIHRvIHRoZSB3aWtpPyZuYnNwOyBZb3UgY291bGQganVzdCB1 cGxvYWQgdGhlIGZpbGUgYW5kIHByb3ZpZGUgYSBsaW5rIHdpdGhvdXQgYWRkaW5nIGFueSBvdGhl ciB0ZXh0IHRvIHRoZSB3aWtpIG9yIHlvdSBjb3VsZCBzZW5kIHRvIG1lIGFuZCBJJ2xsIHVwbG9h ZC4gJm5ic3A7PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSdtIHN1cmUgSSB3aWxs IGxpa2UgaXQgc2luY2UgSSB0aGluayBkaWFncmFtcyBhcmUgZXh0cmVtZWx5IGhlbHBmdWwgaW4g dGhlc2UgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5NYXJ5PG86 cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gVHVlLCBPY3QgMjEsIDIwMTQg YXQgNDo1NiBQTSwgRHVja3dvcnRoLCBNYXJrICZsdDs8YSBocmVmPSJtYWlsdG86TWFyay5EdWNr d29ydGhAcG9seWNvbS5jb20iIHRhcmdldD0iX2JsYW5rIj5NYXJrLkR1Y2t3b3J0aEBwb2x5Y29t LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48cD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SGVyZSBpcyBteSBhdHRlbXB0IGF0IGEgZGlh Z3JhbSB0byBkZXBpY3QgR2xvYmFsIFZpZXdzIGluIGEgR2xvYmFsIFZpZXcgTGlzdC4mbmJzcDsg U2hvdWxkIEkgYWRkIHRoaXMgdG8gdGhlIGZyYW1ld29yayBkb2N1bWVudD8mbmJzcDsgQW55IGNv bW1lbnRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxl PSdmb250LWZhbWlseToiQ291cmllciBOZXciJz5NYXJrPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZu YnNwOyZuYnNwOyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IC4gQWR2ZXJ0aXNlbWVudCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mbmJzcDsmbmJzcDsgLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mbmJzcDsmbmJzcDsgLiArLS0tLS0tLS0tLS0tLS0rJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mbmJzcDsmbmJzcDsgLiB8U2NlbmUgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHxHbG9iYWwgVmlldyBMaXN0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IC4gfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxw PjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgLiB8 IENTVjEgKHYpJmx0Oy0tLS0tLS0tLS0tLS0tLS0tIEdsb2JhbCBWaWV3IChjc3YgMSkmbmJzcDsm bmJzcDsgfCAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgLiB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0tLiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7IC4gfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7ICotLS0tLS0tLS0gR2xv YmFsIFZpZXcgKGNzdiAxLDUpIHwgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IC4gfCBDU1YyICh2KSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IC48L3NwYW4+PG86cD48L286 cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZu YnNwOyAuIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4m bmJzcDsmbmJzcDsgLiB8IENTVjMgKHYpJmx0Oy0tLS0tLS0tLSotLS0tLS0tIEdsb2JhbCBWaWV3 IChjc3YgMyw1KSB8IC48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAuIHwmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyB8IHwmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyB8IC48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAuIHwgQ1NWNCAoYSkmbHQ7LS0tLS0tLS0t LS0tLS0tLS0gR2xvYmFsIFZpZXcgKGNzdiA0KSZuYnNwOyZuYnNwOyB8IC48L3NwYW4+PG86cD48 L286cD48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNw OyZuYnNwOyAuIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJmx0Oy0tLS0tLS0tLS0tLiZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3wgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IC4gKy0tLS0tLS0tLS0tLS0tKyZuYnNwOyB8IHwgKi0t LS0tIEdsb2JhbCBWaWV3IChjc3YgNCw2KSB8IC48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAuJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgfCB8Jm5ic3A7 IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCAuPC9zcGFuPjxvOnA+PC9vOnA+PC9w PjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsg LiArLS0tLS0tLS0tLS0tLS0rJm5ic3A7IHwgfCB8Jm5ic3A7ICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKyAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQ291cmllciBOZXciJz4mbmJzcDsmbmJzcDsgLiB8U2NlbmUgMiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHwgfCB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC48L3NwYW4+PG86cD48L286cD48 L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNw OyAuIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB8IHwgfCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJz cDsmbmJzcDsgLiB8IENTVjUgKHYpJmx0Oy0tLS0tLS0nIHwgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiQ291cmllciBOZXciJz4mbmJzcDsm bmJzcDsgLiB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDstLS0tLS0tLS0nIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHls ZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5ic3A7IC4gfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHYpID0gdmlkZW8mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5i c3A7Jm5ic3A7IC4gfCBDU1Y2IChhKSZsdDstLS0tLS0tLS0tLScmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGEpID0gYXVkaW8mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7Jm5i c3A7IC4gfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IC48L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4gc3R5bGU9 J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOyZuYnNwOyAuICstLS0tLS0tLS0tLS0t LSsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jm5ic3A7Jm5ic3A7IGAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQ291cmllciBOZXciJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHA+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+Y2x1ZSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmNsdWVAaWV0Zi5vcmci PmNsdWVAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2x1ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2x1ZTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AECRPMBOXPRD08p_-- From nobody Wed Oct 22 07:58:06 2014 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 1BC3D1ACD1E for ; Wed, 22 Oct 2014 07:58:04 -0700 (PDT) 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 MQ6_ENyYrQWC for ; Wed, 22 Oct 2014 07:58:00 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311B71ACD36 for ; Wed, 22 Oct 2014 07:57:59 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id l4so2933302lbv.26 for ; Wed, 22 Oct 2014 07:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ad+ULtjf4DNbkK5XxJgVqWI0tnNJU51WnNfJYWHNWQ0=; b=qwlz6ZnUpKjKfs2qmHc5YTZrgITapJfl2UF+f7pmDhSL0F+w2PBlzPYCVKvdx7Iti/ OKxCoE6picDHnijBwmnYKYqn3ihA1OAApKeHYv9Nf6N+GeTh9+xZmDdzK7XeLFlqYx1l tbn59wyyrnw2uzYi0HQpTNZj6hI9+/tfYcNDx71ODSofRj/vbXWTlCh4mqs15QN6FXbI 0eejdyI/baOS7AKMEDuJNScBJUbHCeLfqwDAL0VSrXBTvf8gxOo6MAaDAKW+YxizePhI xq1OpG6Z0bu6QnVCEeNmyskOl47vADyNp/OT0+cYbYUQrFx56BYNj86nDx15i/ArekCj TumQ== MIME-Version: 1.0 X-Received: by 10.112.201.201 with SMTP id kc9mr35938230lbc.76.1413989878420; Wed, 22 Oct 2014 07:57:58 -0700 (PDT) Received: by 10.25.42.136 with HTTP; Wed, 22 Oct 2014 07:57:58 -0700 (PDT) In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AE@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB787AE@CRPMBOXPRD08.polycom.com> Date: Wed, 22 Oct 2014 09:57:58 -0500 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=001a11c2699a6b5bcc0506042cf4 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ycPurtyJ_oc_dEfku55AwzvDs_o Cc: "clue@ietf.org" Subject: Re: [clue] diagram for Global View List 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, 22 Oct 2014 14:58:04 -0000 --001a11c2699a6b5bcc0506042cf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, that's better. So, as an individual, I think it's a good idea to add the diagram to the FW. Mary. On Wed, Oct 22, 2014 at 9:45 AM, Duckworth, Mark wrote: > Can you try viewing it in the email archive? It looks okay there (in > chrome browser, at least). Lines are spaced a bit far apart, but general= ly > it=E2=80=99s readable. > > http://www.ietf.org/mail-archive/web/clue/current/msg04190.html > > > > Mark > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, October 22, 2014 10:41 AM > *To:* Duckworth, Mark > *Cc:* clue@ietf.org > *Subject:* Re: [clue] diagram for Global View List > > > > The diagram doesn't display well with my emailer. Would you mind > uploading the .txt file to the wiki? You could just upload the file and > provide a link without adding any other text to the wiki or you could sen= d > to me and I'll upload. > > > > I'm sure I will like it since I think diagrams are extremely helpful in > these documents. > > > > Thanks, > > Mary > > > > On Tue, Oct 21, 2014 at 4:56 PM, Duckworth, Mark < > Mark.Duckworth@polycom.com> wrote: > > Here is my attempt at a diagram to depict Global Views in a Global View > List. Should I add this to the framework document? Any comments? > > > > Mark > > > > ........................................................ > > . Advertisement . > > . . > > . +--------------+ +-------------------------+ . > > . |Scene 1 | |Global View List | . > > . | | | | . > > . | CSV1 (v)<----------------- Global View (csv 1) | . > > . | <-------. | | . > > . | | *--------- Global View (csv 1,5) | . > > . | CSV2 (v) | | | | . > > . | | | | | . > > . | CSV3 (v)<---------*------- Global View (csv 3,5) | . > > . | | | | | | . > > . | CSV4 (a)<----------------- Global View (csv 4) | . > > . | <-----------. | | . > > . +--------------+ | | *----- Global View (csv 4,6) | . > > . | | | | | . > > . +--------------+ | | | +-------------------------+ . > > . |Scene 2 | | | | . > > . | | | | | . > > . | CSV5 (v)<-------' | | . > > . | <---------' | . > > . | | | (v) =3D video . > > . | CSV6 (a)<-----------' (a) =3D audio . > > . | | . > > . +--------------+ . > > `......................................................' > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > --001a11c2699a6b5bcc0506042cf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, that's better.=C2=A0 So, as an individual, I thi= nk it's a good idea to add the diagram to the FW.

Ma= ry.

On= Wed, Oct 22, 2014 at 9:45 AM, Duckworth, Mark <Mark.Duckworth@po= lycom.com> wrote:

Can you try viewing it in the email archive?=C2=A0 I= t looks okay there (in chrome browser, at least).=C2=A0 Lines are spaced a = bit far apart, but generally it=E2=80=99s readable.

http:= //www.ietf.org/mail-archive/web/clue/current/msg04190.html

=C2=A0=

Mark=

= =C2=A0

= From: Mary Barnes [mailto:mary.ietf.barnes@gmail.co= m]
Sent: Wednesday, October 22, 2014 10:41 AM
To: = Duckworth, Mark
Cc: clue@ietf.org
Subject: Re: [clue] diagram for Global Vi= ew List

=C2=A0

The diag= ram doesn't display well with my emailer.=C2=A0 Would you mind uploadin= g the .txt file to the wiki?=C2=A0 You could just upload the file and provi= de a link without adding any other text to the wiki or you could send to me= and I'll upload. =C2=A0

<= u>=C2=A0

I'm sure I wil= l like it since I think diagrams are extremely helpful in these documents.<= u>

=C2=A0

=

Thanks,

Mary

=C2=A0

On Tue, Oct 21, 20= 14 at 4:56 PM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:=

He= re is my attempt at a diagram to depict Global Views in a Global View List.= =C2=A0 Should I add this to the framework document?=C2=A0 Any comments?

=C2=A0

Mark

=C2=A0

=C2=A0=C2=A0 ..............................= ..........................

=C2=A0=C2=A0 . Advertisement=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0=C2=A0 .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0=C2=A0 . +--------------+=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-------------------------+ .=

=C2=A0=C2=A0 . |Scene 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Global View List=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | .

=C2=A0=C2=A0 . | CSV1 (v)<----= ------------- Global View (csv 1)=C2=A0=C2=A0 | .

<= p>=C2=A0=C2=A0 . |=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-------.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 *--------- Global View (= csv 1,5) | .

=C2=A0=C2=A0 . | CSV2 (v)=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 = |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 | .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0| .

=C2=A0=C2=A0 . | CSV3 (v)<---------*-------= Global View (csv 3,5) | .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | |=C2=A0=C2=A0= =C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 | .

=C2=A0=C2=A0 . | CSV4 (a)<----------------- Global View (csv= 4)=C2=A0=C2=A0 | .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <-----------.=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| .

=C2=A0=C2=A0 . +------------= --+=C2=A0 | | *----- Global View (csv 4,6) | .

<= span style=3D"font-family:"Courier New"">=C2=A0=C2=A0 .=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | | |=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | .

=C2=A0=C2=A0 . +--------------+= =C2=A0 | | |=C2=A0 +-------------------------+ .

=C2=A0=C2=A0 . |Scene = 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | | |=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 | | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .=

= =C2=A0=C2=A0 . | CSV5 (v)<-------' | |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <-----= ----' |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (v) =3D v= ideo=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2= =A0=C2=A0 . | CSV6 (a)<-----------'=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 (a) =3D audio=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 .

=C2=A0=C2=A0 . |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0=C2=A0 . +--------------+=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 .

=C2=A0= =C2=A0 `......................................................'<= u>

=C2= =A0

=C2=A0


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

=C2=A0

<= /div>

--001a11c2699a6b5bcc0506042cf4-- From nobody Thu Oct 23 18:58:48 2014 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 1C88A1AD845 for ; Thu, 23 Oct 2014 18:58:46 -0700 (PDT) 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 ykT8y3q4v3Tk for ; Thu, 23 Oct 2014 18:58:43 -0700 (PDT) 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 736891AD8EA for ; Thu, 23 Oct 2014 18:58:43 -0700 (PDT) Received: from ppp118-209-190-136.lns20.mel8.internode.on.net ([118.209.190.136]:57448 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XhU9E-0002IE-4t for clue@ietf.org; Fri, 24 Oct 2014 12:58:36 +1100 Message-ID: <5449B24B.6020200@nteczone.com> Date: Fri, 24 Oct 2014 12:58:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> In-Reply-To: <034b01cfed72$18953500$49bf9f00$@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/p3MCvE45GBOVok1fWrykyhkWZHs Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 24 Oct 2014 01:58:46 -0000 Hello Roni, Supporting draft-westerlund-avtcore-rtp-simulcast-04 seems like the most straight forward approach as it keeps things at the encoding level, which is really where simulcast belongs. For a CLUE based solution I don't think we need to revert to MCCs. The purpose of simulcast is to provide different encoding options for a particular media stream. A media provider can Advertise a MC with multiple encoding groups. A media consumer if it wants to receive multiple encodings for the same MC can simply choose multiple capture encodings e.g. MC1/Encoding1 MC1/Encoding2 etc. Regards, Christian On 22/10/2014 8:00 AM, Roni Even wrote: > > Hi, > > During our weekly design team meeting we discussed simulcast support > in CLUE. > > Here is my take on the options, my description may not be accurate and > the purpose here is to continue the discussion allowing us to have a > better view of the options. > > Looking at the state of simulcast support in other WGs, there is an > individual draft > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04 > that being discussed. The proposed solution is based on the unified > plan where all encoded streams composing alternatives of a simulcast > stream are in the same m-line. The alternatives are described using an > SDP media level attribute a=simulcast. This attribute is not defined > for SDP session level. > > The first question we had is if we should base CLUE simulcast support > on this individual draft based on CLUE timeline or try to define a > different multicast solution at the CLUE protocol level. > > If we base our solution on the avtcore-rtp-simulcast-04 document the > advertisement will include an individual encoding that will relate to > optional multiple simulcast encoding and the configure will select > such encoding. The actual number of different stream that will compose > the simulcast stream will be negotiated using Offer/Answer as > described in the above document. The risk here is that this is an > individual draft and we may need to review the CLUE support if it > changes. The advantage is that we will have simulcast the same for > CLUE and non-CLUE systems. > > The other option for simulcast support in the CLUE protocol can be > based on having separate Media Capture for each of the different > simulcast encoding and use MCC to compose the simulcast alternatives. > We will need some way to escribe that this MCC is for simulcast > description and to provide the actual allowed individual encodes > combinations for the Configuration by the consumer. > > Thanks > > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Oct 23 19:00:46 2014 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 6D1AD1AD845 for ; Thu, 23 Oct 2014 19:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 igHGumfmo4dy for ; Thu, 23 Oct 2014 19:00:42 -0700 (PDT) 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 E73201AD8EA for ; Thu, 23 Oct 2014 19:00:41 -0700 (PDT) Received: from ppp118-209-190-136.lns20.mel8.internode.on.net ([118.209.190.136]:57459 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XhUB9-0002Xx-NX for clue@ietf.org; Fri, 24 Oct 2014 13:00:35 +1100 Message-ID: <5449B2C3.9020309@nteczone.com> Date: Fri, 24 Oct 2014 13:00:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AA9790A@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6RWiTxSRNS6TF-NaG25JEQWdRbk Subject: Re: [clue] diagram for Global View List 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, 24 Oct 2014 02:00:44 -0000 Hello Mark, It looks OK to me. Regards, Christian On 22/10/2014 8:56 AM, Duckworth, Mark wrote: > > Here is my attempt at a diagram to depict Global Views in a Global > View List. Should I add this to the framework document? Any comments? > > Mark > > ........................................................ > > . Advertisement . > > . . > > . +--------------+ +-------------------------+ . > > . |Scene 1 | |Global View List | . > > . | | | | . > > . | CSV1 (v)<----------------- Global View (csv 1) | . > > . | <-------. | | . > > . | | *--------- Global View (csv 1,5) | . > > . | CSV2 (v) | | | | . > > . | | | | | . > > . | CSV3 (v)<---------*------- Global View (csv 3,5) | . > > . | | | | | | . > > . | CSV4 (a)<----------------- Global View (csv 4) | . > > . | <-----------. | | . > > . +--------------+ | | *----- Global View (csv 4,6) | . > > . | | | | | . > > . +--------------+ | | | +-------------------------+ . > > . |Scene 2 | | | | . > > . | | | | | . > > . | CSV5 (v)<-------' | | . > > . | <---------' | . > > . | | | (v) = video . > > . | CSV6 (a)<-----------' (a) = audio . > > . | | . > > . +--------------+ . > > `......................................................' > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Oct 24 05:19:21 2014 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 7844D1A8AEB for ; Fri, 24 Oct 2014 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 IpOKz3zIE5pn for ; Fri, 24 Oct 2014 05:19:07 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3891A8ADE for ; Fri, 24 Oct 2014 05:19:06 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id gf13so1187806lab.36 for ; Fri, 24 Oct 2014 05:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=6QEIE/SIUN3gYETtiplLuEp2yyLDmvW03K4VrBRNsSc=; b=0Q7galrS0xXLFMJpOkSf9vV0yIMEhsmbeuEIVBzzuTHswhRe+vDZh0tQoWlqtxSNW9 BKSkQLHJi1FdDqAKsXcH4RzX9FTc1JIeqcLWPicnjzkrCt/SsIaAvNVEiijoDmVdlPRC XwWa+7qrhtZPDv431QyNVOhI9aDYR5e+BbE3V6xr7fGdlXgQ6oafSlz0IcJGse2r/Oko H7n/v07xmrzP6KSRYJ+cJ3BxBx7IZZ7n8KsMcNB7wlE8hWU3ef6Iojbw5Wa+d50311dU dtXEA4D3ErWGRPm8A7xMDRc1mdqkrQQvpXGWvAwzdg8+AFGb3XjsdLamqGuRPocPI1Uc 35wg== X-Received: by 10.152.21.39 with SMTP id s7mr4229774lae.0.1414153145028; Fri, 24 Oct 2014 05:19:05 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id ck6sm1801486lbb.45.2014.10.24.05.19.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Oct 2014 05:19:04 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> In-Reply-To: <5449B24B.6020200@nteczone.com> Date: Fri, 24 Oct 2014 15:18:53 +0300 Message-ID: <05f501cfef84$b241ec20$16c5c460$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrm/PMf6A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/hrozevDwFJ_RhKmdA0g5m_Ticy4 Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 24 Oct 2014 12:19:11 -0000 Hi Christian, Inline Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 24 October, 2014 4:59 AM > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > Hello Roni, > > Supporting draft-westerlund-avtcore-rtp-simulcast-04 > > seems like the most straight forward approach as it keeps things at the > encoding level, which is really where simulcast belongs. > > For a CLUE based solution I don't think we need to revert to MCCs. The purpose > of simulcast is to provide different encoding options for a particular media > stream. A media provider can Advertise a MC with multiple encoding groups. A > media consumer if it wants to receive multiple encodings for the same MC can > simply choose multiple capture encodings e.g. MC1/Encoding1 MC1/Encoding2 > etc. [Roni Even] How does the media consumer know that these are alternatives of a simulcast stream and know how many can be used at the same time. You also lose here the option of the total BW that is an encoding group attribute. All these means that we need some changes to CLUE and we can look at what will make the best solution using MCs or MMCs. Still the question is if we say that we will use the SDP based solution even though it is not a WG draft, having it as a normative reference will delay the publication of the CLUE draft > > Regards, Christian > > On 22/10/2014 8:00 AM, Roni Even wrote: > > > > Hi, > > > > During our weekly design team meeting we discussed simulcast support > > in CLUE. > > > > Here is my take on the options, my description may not be accurate and > > the purpose here is to continue the discussion allowing us to have a > > better view of the options. > > > > Looking at the state of simulcast support in other WGs, there is an > > individual draft > > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04 > > that being discussed. The proposed solution is based on the unified > > plan where all encoded streams composing alternatives of a simulcast > > stream are in the same m-line. The alternatives are described using an > > SDP media level attribute "a=simulcast". This attribute is not defined > > for SDP session level. > > > > The first question we had is if we should base CLUE simulcast support > > on this individual draft based on CLUE timeline or try to define a > > different multicast solution at the CLUE protocol level. > > > > If we base our solution on the avtcore-rtp-simulcast-04 document the > > advertisement will include an individual encoding that will relate to > > optional multiple simulcast encoding and the configure will select > > such encoding. The actual number of different stream that will compose > > the simulcast stream will be negotiated using Offer/Answer as > > described in the above document. The risk here is that this is an > > individual draft and we may need to review the CLUE support if it > > changes. The advantage is that we will have simulcast the same for > > CLUE and non-CLUE systems. > > > > The other option for simulcast support in the CLUE protocol can be > > based on having separate Media Capture for each of the different > > simulcast encoding and use MCC to compose the simulcast alternatives. > > We will need some way to escribe that this MCC is for simulcast > > description and to provide the actual allowed individual encodes > > combinations for the Configuration by the consumer. > > > > Thanks > > > > Roni > > > > > > > > _______________________________________________ > > 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 Oct 24 06:10:19 2014 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 657141A0049; Fri, 24 Oct 2014 06:10:16 -0700 (PDT) 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 JylOzE_bzunJ; Fri, 24 Oct 2014 06:10:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 320461A0076; Fri, 24 Oct 2014 06:10:07 -0700 (PDT) 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.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 06:10:07 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/IMrlPrd1Xcm9WEdDTQ4Aqh9Hcp0 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-02.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, 24 Oct 2014 13:10:16 -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 Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-02.txt Pages : 59 Date : 2014-10-24 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a CLUE telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined, respectively, in [I-D.ietf-clue-framework] and [I-D.ietf-clue-telepresence-requirements]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-protocol-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02 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 Oct 24 06:42:47 2014 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 4D4331A0097 for ; Fri, 24 Oct 2014 06:42:36 -0700 (PDT) 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 ZyVoluGki1gE for ; Fri, 24 Oct 2014 06:42:33 -0700 (PDT) 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 86CF51A00E4 for ; Fri, 24 Oct 2014 06:42:29 -0700 (PDT) X-ASG-Debug-ID: 1414158146-05ce3723b75240e0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id xPUPF5riAJSuwOvt (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 24 Oct 2014 15:42:26 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([143.225.229.123]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s9ODgPuo009204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Oct 2014 15:42:25 +0200 Message-ID: <544A5742.6050606@unina.it> Date: Fri, 24 Oct 2014 15:42:26 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt In-Reply-To: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030303050706080808050307" X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1414158146 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.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.10880 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/uymQPXQNQVIr1uj252XFKoFW5Jg Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:42:36 -0000 This is a multi-part message in MIME format. --------------030303050706080808050307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, we have just uploaded the new version of the protocol document to be discussed in the next call. In the following the diff with version 01. Best regards, Roberta o The diff mechanism for the ADV message has been introduced. o READV and READV RESPONSE message have been both removed. o The state machines have been deeply reviewed and changed. o References: references have been updated and splitted into Informative references and Normative references as in framework v17. o Schema: changed in , in o Terminology: many definitions added. Response codes updated. Il 24/10/2014 15:10, internet-drafts@ietf.org ha scritto: > 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 > Authors : Roberta Presta > Simon Pietro Romano > Filename : draft-ietf-clue-protocol-02.txt > Pages : 59 > Date : 2014-10-24 > > Abstract: > The CLUE protocol is an application protocol conceived for the > description and negotiation of a CLUE telepresence session. The > design of the CLUE protocol takes into account the requirements and > the framework defined, respectively, in [I-D.ietf-clue-framework] and > [I-D.ietf-clue-telepresence-requirements]. The companion document > [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well > as on the SIP/SDP session establishment phase. CLUE messages flow > upon the CLUE data channel, based on reliable and ordered SCTP over > DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message > details, together with the behavior of CLUE Participants acting as > Media Providers and/or Media Consumers, are herein discussed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-protocol-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --------------030303050706080808050307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,
we have just uploaded the new version of the protocol document to be discussed in the next call.
In the following the diff with version 01.
Best regards,

Roberta

   o  The diff mechanism for the ADV message has been introduced.

   o  READV and READV RESPONSE message have been both removed.

   o  The state machines have been deeply reviewed and changed.

   o  References: references have been updated and splitted into
      Informative references and Normative references as in framework
      v17.

   o  Schema: <globalSceneEntries> changed in <globalViews>,
      <participants> in <people>

   o  Terminology: many definitions added. Response codes updated.





Il 24/10/2014 15:10, internet-drafts@ietf.org ha scritto:
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
        Authors         : Roberta Presta
                          Simon Pietro Romano
	Filename        : draft-ietf-clue-protocol-02.txt
	Pages           : 59
	Date            : 2014-10-24

Abstract:
   The CLUE protocol is an application protocol conceived for the
   description and negotiation of a CLUE telepresence session.  The
   design of the CLUE protocol takes into account the requirements and
   the framework defined, respectively, in [I-D.ietf-clue-framework] and
   [I-D.ietf-clue-telepresence-requirements].  The companion document
   [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well
   as on the SIP/SDP session establishment phase.  CLUE messages flow
   upon the CLUE data channel, based on reliable and ordered SCTP over
   DTLS transport, as described in [I-D.ietf-clue-datachannel].  Message
   details, together with the behavior of CLUE Participants acting as
   Media Providers and/or Media Consumers, are herein discussed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-protocol-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02


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

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

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

--------------030303050706080808050307-- From nobody Fri Oct 24 06:50:39 2014 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 5901B1A010D for ; Fri, 24 Oct 2014 06:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QaojD4cYCC_w for ; Fri, 24 Oct 2014 06:50:28 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769AB1A013B for ; Fri, 24 Oct 2014 06:50:08 -0700 (PDT) Received: from [216.82.254.20:48995] by server-9.bemta-7.messagelabs.com id CD/0B-03013-F095A445; Fri, 24 Oct 2014 13:50:07 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1414158606!12872651!5 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26899 invoked from network); 24 Oct 2014 13:50:07 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2014 13:50:07 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 24 Oct 2014 06:47:55 -0700 From: "Duckworth, Mark" To: Roni Even , 'Christian Groves' , "clue@ietf.org" Date: Fri, 24 Oct 2014 06:47:34 -0700 Thread-Topic: [clue] CLUE and Simulcast - ticket #47 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrm/PMf6CAABcisA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> In-Reply-To: <05f501cfef84$b241ec20$16c5c460$@gmail.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: http://mailarchive.ietf.org/arch/msg/clue/2-3hjlao0hBWY8sUe3xOn9gH4dg Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 24 Oct 2014 13:50:32 -0000 Hello Roni and Christian, I believe CLUE already supports simulcast today, basically as Christian des= cribes. More below. (trying to use both the "correct indentation with > > symbols", and also ma= rking comments with my name :-) Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Friday, October 24, 2014 8:19 AM > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 >=20 > Hi Christian, > Inline > Roni >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > > Sent: 24 October, 2014 4:59 AM > > To: clue@ietf.org > > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > > > Hello Roni, > > > > Supporting draft-westerlund-avtcore-rtp-simulcast-04 > > > > seems like the most straight forward approach as it keeps things at the > > encoding level, which is really where simulcast belongs. [Duckworth, Mark] Does CLUE really need to say anything about this? Isn't this separate from CLUE, and can be used with CLUE without any furthe= r specification in CLUE documents? > > For a CLUE based solution I don't think we need to revert to MCCs. The = purpose > > of simulcast is to provide different encoding options for a particular = media > > stream. A media provider can Advertise a MC with multiple encoding grou= ps. > > A media consumer if it wants to receive multiple encodings for the same= MC > > can simply choose multiple capture encodings e.g. MC1/Encoding1 > > MC1/Encoding2 etc. [Duckworth, Mark] Yes, a media provider can support multiple encodings for = the same MC, and a consumer can choose to configure multiple encodings for the= =20 same MC. You don't even need multiple encoding groups to do this, you can = do=20 it with just one group that contains multiple encodings. > [Roni Even] How does the media consumer know that these are alternatives = of > a simulcast stream and know how many can be used at the same time. [Duckworth, Mark] By the MC attribute "max capture encodings". Any encodin= gs in the MC's encoding groups can be configured for a particular MC, simultan= eously, up to the value of "max capture encodings". >You also lose here the option of the total BW that is an encoding group at= tribute. [Duckworth, Mark] You can still use that by advertising an MC with a single= encoding group, with multiple encodings in the group. > All these means that we need some changes to CLUE and we can look at what > will make the best solution using MCs or MMCs. [Duckworth, Mark] I believe we don't need any changes in CLUE, all this is= =20 already supported. > Still the question is if we say that we will use the SDP based solution e= ven > though it is not a WG draft, having it as a normative reference will dela= y > the publication of the CLUE draft >=20 > > > > Regards, Christian > > > > On 22/10/2014 8:00 AM, Roni Even wrote: > > > > > > Hi, > > > > > > During our weekly design team meeting we discussed simulcast support > > > in CLUE. > > > > > > Here is my take on the options, my description may not be accurate an= d > > > the purpose here is to continue the discussion allowing us to have a > > > better view of the options. > > > > > > Looking at the state of simulcast support in other WGs, there is an > > > individual draft > > > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04 > > > that being discussed. The proposed solution is based on the unified > > > plan where all encoded streams composing alternatives of a simulcast > > > stream are in the same m-line. The alternatives are described using a= n > > > SDP media level attribute "a=3Dsimulcast". This attribute is not defi= ned > > > for SDP session level. > > > > > > The first question we had is if we should base CLUE simulcast support > > > on this individual draft based on CLUE timeline or try to define a > > > different multicast solution at the CLUE protocol level. > > > > > > If we base our solution on the avtcore-rtp-simulcast-04 document the > > > advertisement will include an individual encoding that will relate to > > > optional multiple simulcast encoding and the configure will select > > > such encoding. The actual number of different stream that will compos= e > > > the simulcast stream will be negotiated using Offer/Answer as > > > described in the above document. The risk here is that this is an > > > individual draft and we may need to review the CLUE support if it > > > changes. The advantage is that we will have simulcast the same for > > > CLUE and non-CLUE systems. > > > > > > The other option for simulcast support in the CLUE protocol can be > > > based on having separate Media Capture for each of the different > > > simulcast encoding and use MCC to compose the simulcast alternatives. > > > We will need some way to escribe that this MCC is for simulcast > > > description and to provide the actual allowed individual encodes > > > combinations for the Configuration by the consumer. > > > > > > Thanks > > > > > > Roni From nobody Fri Oct 24 08:44:06 2014 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 478E31A1AA8; Fri, 24 Oct 2014 08:44:02 -0700 (PDT) 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 X9MD7XK1i-Vk; Fri, 24 Oct 2014 08:44:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D67311A1AB0; Fri, 24 Oct 2014 08:43:02 -0700 (PDT) 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.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024154302.4408.26305.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 08:43:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/E4k8RW8tCAJYTNBoBhW4rm4u9yU Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-18.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, 24 Oct 2014 15:44:02 -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-18.txt Pages : 80 Date : 2014-10-24 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-18 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 Oct 24 08:48:36 2014 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 B55F71A1A9C for ; Fri, 24 Oct 2014 08:48:34 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Ol7nqyobu7Wi for ; Fri, 24 Oct 2014 08:48:33 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87C11A1AE5 for ; Fri, 24 Oct 2014 08:47:44 -0700 (PDT) Received: from [216.82.249.212:10813] by server-10.bemta-12.messagelabs.com id 6A/12-09904-0A47A445; Fri, 24 Oct 2014 15:47:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1414165663!12559221!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2696 invoked from network); 24 Oct 2014 15:47:44 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-7.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 24 Oct 2014 15:47:44 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 24 Oct 2014 08:45:02 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 24 Oct 2014 08:44:41 -0700 Thread-Topic: Updates in framework-18 Thread-Index: Ac/voUwAVwBnpHLITJybUdEi4B+uIw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78AC3@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VPYL7gtdfp6sV5QUkLt5NZWKsWg Subject: [clue] Updates in framework-18 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, 24 Oct 2014 15:48:34 -0000 Very small changes this time. 1. Add separate definition of Global View List. 2. Add diagram for Global View List structure. 3. Tweak definitions of Media Consumer and Provider. Regards, Mark From nobody Fri Oct 24 10:02:43 2014 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 500781A86DE for ; Fri, 24 Oct 2014 10:02:40 -0700 (PDT) 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 lDNRe2wWAHZi for ; Fri, 24 Oct 2014 10:02:38 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BDDD1A8A0C for ; Fri, 24 Oct 2014 09:57:16 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-10v.sys.comcast.net with comcast id 74x81p0074yXVJQ014xFxT; Fri, 24 Oct 2014 16:57:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 74xF1p00F3Ge9ey014xF9T; Fri, 24 Oct 2014 16:57:15 +0000 Message-ID: <544A84EB.8060203@alum.mit.edu> Date: Fri, 24 Oct 2014 12:57:15 -0400 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: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@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=1414169835; bh=bWXlcBFpRbruyLZH80PEYadbZAa2jfSKI2ecYqPxKt4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JxsCZI5CpuIKnZxgWkRuudP9zCHuBLNdUQDqyvtYrJI13H2tAqZRoI32AuqKZ5xiD eWgKhp8wHE9hyu6Opb3ldLdCoGkcz8gMOcDyZq5bHUyW7diOlNJntewv5CIjPZEQVj Wui36KEaZFbXzTA14dwHMCQjYRwBFT6KzK3F42JAKhjfJ98l9iJW2fTg01r3mQ2iI2 yErgH/TEIwcTKeJnpGcssZSk6nvJ0pwhUGtDVaj1niuB5q4R7n7WE4hncIBW4/d1mc QkQC8bErcbD52cNVRQt1lLAxGAkuTrF5JtIKPFbO46w8MoayWY3TpE0DW/ANRBJn7R SkARnYeIaPEyw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Kvhq1G9JwoC7S39psIGG31gQyCQ Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 24 Oct 2014 17:02:40 -0000 I agree with Mark here. Consider a plausible use case in clue: The advertiser has a number of captures, and has a number of encoders. It can create an encoding group with all the encoders in it - some do hi-res video, some do small videos. It puts all of those in an encoding group and associates all the captures with that group. A "normal" consumer might configure a few of the captures with the hi-res encodings, and some of the other captures with the small encodings. There would be no simulcast in this case. Some other consumer (e.g., an MCC) may decide it wants one of the captures in both big and small versions of one of the MCCs. It can simply do an appropriate configuration and get that. Now we have *simulcast*! The advertiser didn't have to do anything special - didn't have to think about simulcast at all. If an advertiser *wants* to use draft-westerlund-avtcore-rtp-simulcast then I see no reason to prevent that. But I would hate to force that (especially since it isn't approved yet). Thanks, Paul On 10/24/14 9:47 AM, Duckworth, Mark wrote: > Hello Roni and Christian, > > I believe CLUE already supports simulcast today, basically as Christian describes. > > More below. > > (trying to use both the "correct indentation with > > symbols", and also marking > comments with my name :-) > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >> Sent: Friday, October 24, 2014 8:19 AM >> To: 'Christian Groves'; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> Hi Christian, >> Inline >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >>> Sent: 24 October, 2014 4:59 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>> >>> Hello Roni, >>> >>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 >>> >>> seems like the most straight forward approach as it keeps things at the >>> encoding level, which is really where simulcast belongs. > > [Duckworth, Mark] Does CLUE really need to say anything about this? > Isn't this separate from CLUE, and can be used with CLUE without any further > specification in CLUE documents? > >>> For a CLUE based solution I don't think we need to revert to MCCs. The purpose >>> of simulcast is to provide different encoding options for a particular media >>> stream. A media provider can Advertise a MC with multiple encoding groups. >>> A media consumer if it wants to receive multiple encodings for the same MC >>> can simply choose multiple capture encodings e.g. MC1/Encoding1 >>> MC1/Encoding2 etc. > > [Duckworth, Mark] Yes, a media provider can support multiple encodings for the > same MC, and a consumer can choose to configure multiple encodings for the > same MC. You don't even need multiple encoding groups to do this, you can do > it with just one group that contains multiple encodings. > >> [Roni Even] How does the media consumer know that these are alternatives of >> a simulcast stream and know how many can be used at the same time. > > [Duckworth, Mark] By the MC attribute "max capture encodings". Any encodings > in the MC's encoding groups can be configured for a particular MC, simultaneously, > up to the value of "max capture encodings". > >> You also lose here the option of the total BW that is an encoding group attribute. > > [Duckworth, Mark] You can still use that by advertising an MC with a single encoding > group, with multiple encodings in the group. > >> All these means that we need some changes to CLUE and we can look at what >> will make the best solution using MCs or MMCs. > > [Duckworth, Mark] I believe we don't need any changes in CLUE, all this is > already supported. > >> Still the question is if we say that we will use the SDP based solution even >> though it is not a WG draft, having it as a normative reference will delay >> the publication of the CLUE draft >> >>> >>> Regards, Christian >>> >>> On 22/10/2014 8:00 AM, Roni Even wrote: >>>> >>>> Hi, >>>> >>>> During our weekly design team meeting we discussed simulcast support >>>> in CLUE. >>>> >>>> Here is my take on the options, my description may not be accurate and >>>> the purpose here is to continue the discussion allowing us to have a >>>> better view of the options. >>>> >>>> Looking at the state of simulcast support in other WGs, there is an >>>> individual draft >>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-04 >>>> that being discussed. The proposed solution is based on the unified >>>> plan where all encoded streams composing alternatives of a simulcast >>>> stream are in the same m-line. The alternatives are described using an >>>> SDP media level attribute "a=simulcast". This attribute is not defined >>>> for SDP session level. >>>> >>>> The first question we had is if we should base CLUE simulcast support >>>> on this individual draft based on CLUE timeline or try to define a >>>> different multicast solution at the CLUE protocol level. >>>> >>>> If we base our solution on the avtcore-rtp-simulcast-04 document the >>>> advertisement will include an individual encoding that will relate to >>>> optional multiple simulcast encoding and the configure will select >>>> such encoding. The actual number of different stream that will compose >>>> the simulcast stream will be negotiated using Offer/Answer as >>>> described in the above document. The risk here is that this is an >>>> individual draft and we may need to review the CLUE support if it >>>> changes. The advantage is that we will have simulcast the same for >>>> CLUE and non-CLUE systems. >>>> >>>> The other option for simulcast support in the CLUE protocol can be >>>> based on having separate Media Capture for each of the different >>>> simulcast encoding and use MCC to compose the simulcast alternatives. >>>> We will need some way to escribe that this MCC is for simulcast >>>> description and to provide the actual allowed individual encodes >>>> combinations for the Configuration by the consumer. >>>> >>>> Thanks >>>> >>>> Roni > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Oct 24 12:24:55 2014 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 4F05A1A1A38 for ; Fri, 24 Oct 2014 12:24:52 -0700 (PDT) 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 0IlLQ6GgoRiF for ; Fri, 24 Oct 2014 12:24:51 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068621A19F1 for ; Fri, 24 Oct 2014 12:24:50 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-10v.sys.comcast.net with comcast id 77Nn1p00652QWKC017QqZK; Fri, 24 Oct 2014 19:24:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-09v.sys.comcast.net with comcast id 77Qp1p00R3Ge9ey017QqBm; Fri, 24 Oct 2014 19:24:50 +0000 Message-ID: <544AA781.5040103@alum.mit.edu> Date: Fri, 24 Oct 2014 15:24:49 -0400 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: <20141024154302.4408.26305.idtracker@ietfa.amsl.com> In-Reply-To: <20141024154302.4408.26305.idtracker@ietfa.amsl.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=1414178690; bh=14meHcHxMtoTHVPLXNtK+6B+MkwnlHtF9jx/donO4/c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CO4EQQHFeUxNqNjW2vo/XSjOB1AZLpxyGRRIa6cIQwdrKNRXwlTSAWHpeWfyJLOKq xrVqPmheIVfni+RIh2npdqkMc5GQzFPsp/yfqlArsOy8rszhIT/G8fgAgUHj2Eza+y lk3aRr0/iLmETDQyNPM3m9bodl0wPaWVvKcSvqoqyMDZw4VNwWHEJKt/ah+/g11h6c DknUUPYwZcQXpMMhJ2ycxqtlgN+ZxCj/RYBXYRnZiMSGxrp7qSQCCy1jkMPnffjei1 BxRFvQ3BTvyw2E7M1yYYmRKyzXZpQPTczPqEbqqNtQpdVoZXlhlbDQ564j8ejqq8g7 dNtMT6ZNQjXhA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NxEZxmGQkPhMdjCUA_r26wDP-kA Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-18.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 19:24:52 -0000 Looks good to me. Thanks, Paul On 10/24/14 11:43 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Framework for Telepresence Multi-Streams > Authors : Mark Duckworth > Andrew Pepperell > Stephan Wenger > Filename : draft-ietf-clue-framework-18.txt > Pages : 80 > Date : 2014-10-24 > > Abstract: > This document defines a framework for a protocol to enable devices > in a telepresence conference to interoperate. The protocol enables > communication of information about multiple media streams so a > sending system and receiving system can make reasonable decisions > about transmitting, selecting and rendering the media streams. > This protocol is used in addition to SIP signaling for setting up a > telepresence session. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-framework-18 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-18 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sat Oct 25 07:54:00 2014 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 BC6401A0010 for ; Sat, 25 Oct 2014 07:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 gJPMf5aP8FYQ for ; Sat, 25 Oct 2014 07:53:46 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D3A1A0081 for ; Sat, 25 Oct 2014 07:53:46 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id 10so3890268lbg.18 for ; Sat, 25 Oct 2014 07:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=c9KaOmfCipYhv1I8SsMeWsJK28pEMcuZ0AbAn4SNs9w=; b=Ka6A24/AexWmrePMuisUR5Ta6TizKJO31hn1mtDLRqRavf3La1oKTA2E9fgQQb4aYC flK0JqP8iENXJkJ9PBCOSZb/8FVVMgv2eP1AKc3u/c0UPNAo4rQqNlk5fwsbtKIsbAsE s7NYd+aZGVS9onChfCRV2a5HwIXb5UvnLehJg2f/t1rWowY8e6UkqTFa6g9NLV2ppSvB CeI26F3LjyzZtAsaHWKjz25Zw20IxtuV5cJcHpH3uWpktjVs2g4O23pTqUG2F3oTtWR0 aiFSbSt0ae7nbhOWjbjXl0npecPpZ140U43N271ebUXUZ8DsHxDKQ2laVwSibGUP4ySw fzbA== X-Received: by 10.152.29.8 with SMTP id f8mr11411880lah.56.1414248824406; Sat, 25 Oct 2014 07:53:44 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id w10sm2972003laz.28.2014.10.25.07.53.42 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Oct 2014 07:53:43 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> In-Reply-To: <544A84EB.8060203@alum.mit.edu> Date: Sat, 25 Oct 2014 17:53:34 +0300 Message-ID: <066401cff063$773033f0$65909bd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAm83StCA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/M8u-a6ZXOKRRBPPP2K5QmJJ9DJY Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 14:53:49 -0000 Hi Paul, Inline Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 24 October, 2014 7:57 PM > To: clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > I agree with Mark here. > > Consider a plausible use case in clue: > > The advertiser has a number of captures, and has a number of encoders. > It can create an encoding group with all the encoders in it - some do hi-res > video, some do small videos. It puts all of those in an encoding group and > associates all the captures with that group. > > A "normal" consumer might configure a few of the captures with the hi-res > encodings, and some of the other captures with the small encodings. There > would be no simulcast in this case. > > Some other consumer (e.g., an MCC) may decide it wants one of the captures > in both big and small versions of one of the MCCs. It can simply do an > appropriate configuration and get that. Now we have *simulcast*! The > advertiser didn't have to do anything special - didn't have to think about > simulcast at all. [Roni Even] How does the consumer know that these MCs are different potential encodings of the same source. Marks, suggested different encoding group for each encoding so he can advertise MC1 with ENC1 and ENC2, in this case the encoding groups will represent different encoding parameters but will need to be defined accordingly, for example one encoding group that has CIF resolutions and the other with only HD resolutions > > If an advertiser *wants* to use draft-westerlund-avtcore-rtp-simulcast > then I see no reason to prevent that. But I would hate to force that (especially > since it isn't approved yet). > > Thanks, > Paul > > On 10/24/14 9:47 AM, Duckworth, Mark wrote: > > Hello Roni and Christian, > > > > I believe CLUE already supports simulcast today, basically as Christian > describes. > > > > More below. > > > > (trying to use both the "correct indentation with > > symbols", and > > also marking comments with my name :-) > > > > Mark > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > >> Sent: Friday, October 24, 2014 8:19 AM > >> To: 'Christian Groves'; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> Hi Christian, > >> Inline > >> Roni > >> > >>> -----Original Message----- > >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>> Groves > >>> Sent: 24 October, 2014 4:59 AM > >>> To: clue@ietf.org > >>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>> > >>> Hello Roni, > >>> > >>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>> >>> 4> seems like the most straight forward approach as it keeps things > >>> at the encoding level, which is really where simulcast belongs. > > > > [Duckworth, Mark] Does CLUE really need to say anything about this? > > Isn't this separate from CLUE, and can be used with CLUE without any > > further specification in CLUE documents? > > > >>> For a CLUE based solution I don't think we need to revert to MCCs. > >>> The purpose of simulcast is to provide different encoding options > >>> for a particular media stream. A media provider can Advertise a MC with > multiple encoding groups. > >>> A media consumer if it wants to receive multiple encodings for the > >>> same MC can simply choose multiple capture encodings e.g. > >>> MC1/Encoding1 > >>> MC1/Encoding2 etc. > > > > [Duckworth, Mark] Yes, a media provider can support multiple encodings > > for the same MC, and a consumer can choose to configure multiple > > encodings for the same MC. You don't even need multiple encoding > > groups to do this, you can do it with just one group that contains multiple > encodings. > > > >> [Roni Even] How does the media consumer know that these are > >> alternatives of a simulcast stream and know how many can be used at the > same time. > > > > [Duckworth, Mark] By the MC attribute "max capture encodings". Any > > encodings in the MC's encoding groups can be configured for a > > particular MC, simultaneously, up to the value of "max capture encodings". > > > >> You also lose here the option of the total BW that is an encoding group > attribute. > > > > [Duckworth, Mark] You can still use that by advertising an MC with a > > single encoding group, with multiple encodings in the group. > > > >> All these means that we need some changes to CLUE and we can look at > >> what will make the best solution using MCs or MMCs. > > > > [Duckworth, Mark] I believe we don't need any changes in CLUE, all > > this is already supported. > > > >> Still the question is if we say that we will use the SDP based > >> solution even though it is not a WG draft, having it as a normative > >> reference will delay the publication of the CLUE draft > >> > >>> > >>> Regards, Christian > >>> > >>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>> > >>>> Hi, > >>>> > >>>> During our weekly design team meeting we discussed simulcast > >>>> support in CLUE. > >>>> > >>>> Here is my take on the options, my description may not be accurate > >>>> and the purpose here is to continue the discussion allowing us to > >>>> have a better view of the options. > >>>> > >>>> Looking at the state of simulcast support in other WGs, there is an > >>>> individual draft > >>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-0 > >>>> 4 that being discussed. The proposed solution is based on the > >>>> unified plan where all encoded streams composing alternatives of a > >>>> simulcast stream are in the same m-line. The alternatives are > >>>> described using an SDP media level attribute "a=simulcast". This > >>>> attribute is not defined for SDP session level. > >>>> > >>>> The first question we had is if we should base CLUE simulcast > >>>> support on this individual draft based on CLUE timeline or try to > >>>> define a different multicast solution at the CLUE protocol level. > >>>> > >>>> If we base our solution on the avtcore-rtp-simulcast-04 document > >>>> the advertisement will include an individual encoding that will > >>>> relate to optional multiple simulcast encoding and the configure > >>>> will select such encoding. The actual number of different stream > >>>> that will compose the simulcast stream will be negotiated using > >>>> Offer/Answer as described in the above document. The risk here is > >>>> that this is an individual draft and we may need to review the CLUE > >>>> support if it changes. The advantage is that we will have simulcast > >>>> the same for CLUE and non-CLUE systems. > >>>> > >>>> The other option for simulcast support in the CLUE protocol can be > >>>> based on having separate Media Capture for each of the different > >>>> simulcast encoding and use MCC to compose the simulcast alternatives. > >>>> We will need some way to escribe that this MCC is for simulcast > >>>> description and to provide the actual allowed individual encodes > >>>> combinations for the Configuration by the consumer. > >>>> > >>>> Thanks > >>>> > >>>> Roni > > > > _______________________________________________ > > 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 Oct 26 14:33:54 2014 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 E9E1A1A0A6A for ; Sun, 26 Oct 2014 14:33:51 -0700 (PDT) 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 b0O-LDHWm1m2 for ; Sun, 26 Oct 2014 14:33:49 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB20F1A01F0 for ; Sun, 26 Oct 2014 14:33:49 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-09v.sys.comcast.net with comcast id 7xZL1p0014xDoy801xZppL; Sun, 26 Oct 2014 21:33:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id 7xZn1p0033Ge9ey01xZnDW; Sun, 26 Oct 2014 21:33:48 +0000 Message-ID: <544D68BB.9060701@alum.mit.edu> Date: Sun, 26 Oct 2014 17:33:47 -0400 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: Roni Even , clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> In-Reply-To: <066401cff063$773033f0$65909bd0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414359229; bh=XPJKwNcE+Rbgb4k4e1TwyuvB/8UXDI3BzqAajddVCzk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=n1VKGmRryoJnRj0ycm2U+VmGkUAJjmukiNy4U13RZUrtvXqanXXdTETxhl/uI69wQ lCWwe06/ZPOcVdqOKyUk534IXF9VLmqxQm849apB/506pGQLUXeTpaClLGDfJUXzOO r7U8jPlk1KwZwnYUr78vP3rMfwk7sR3s4Do6LazB+SyKhG8ZAZVPoqfozPLxFB/uIU uiWcbpchS3YpzbURzTpzEUD7e+aXCBKcUiT7VWLPaxwj3js/UClMbkZqUSYoc3/oaP L/0isH3WrViJoYs3WsKOR7k+U2hjDG5G4G2FulCFCSEIqXgphUMH0XmwdMCIlPtSg0 zJ3vUrkuGsmlA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-Hr7y7tyqXzJ1TvPBE7gz4rnSpA Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 21:33:52 -0000 On 10/25/14 10:53 AM, Roni Even wrote: > Hi Paul, > Inline > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 24 October, 2014 7:57 PM >> To: clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> I agree with Mark here. >> >> Consider a plausible use case in clue: >> >> The advertiser has a number of captures, and has a number of encoders. >> It can create an encoding group with all the encoders in it - some do > hi-res >> video, some do small videos. It puts all of those in an encoding group and >> associates all the captures with that group. >> >> A "normal" consumer might configure a few of the captures with the hi-res >> encodings, and some of the other captures with the small encodings. There >> would be no simulcast in this case. >> >> Some other consumer (e.g., an MCC) may decide it wants one of the captures >> in both big and small versions of one of the MCCs. It can simply do an >> appropriate configuration and get that. Now we have *simulcast*! The >> advertiser didn't have to do anything special - didn't have to think about >> simulcast at all. > [Roni Even] How does the consumer know that these MCs are different > potential encodings of the same source. > Marks, suggested different encoding group for each encoding so he can > advertise MC1 with ENC1 and ENC2, in this case the encoding groups will > represent different encoding parameters but will need to be defined > accordingly, for example one encoding group that has CIF resolutions and the > other with only HD resolutions This works when the advertisement assigns the capture to an encoding group containing multiple encodings. When the consumer configures the same encoding twice, using different encodings from the encoding group, then he knows - by definition - they are simulcasts. Thanks, Paul >> If an advertiser *wants* to use draft-westerlund-avtcore-rtp-simulcast >> then I see no reason to prevent that. But I would hate to force that > (especially >> since it isn't approved yet). >> >> Thanks, >> Paul >> >> On 10/24/14 9:47 AM, Duckworth, Mark wrote: >>> Hello Roni and Christian, >>> >>> I believe CLUE already supports simulcast today, basically as Christian >> describes. >>> >>> More below. >>> >>> (trying to use both the "correct indentation with > > symbols", and >>> also marking comments with my name :-) >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>> Sent: Friday, October 24, 2014 8:19 AM >>>> To: 'Christian Groves'; clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> Hi Christian, >>>> Inline >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>> Groves >>>>> Sent: 24 October, 2014 4:59 AM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>> >>>>> Hello Roni, >>>>> >>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 >>>>> >>>> 4> seems like the most straight forward approach as it keeps things >>>>> at the encoding level, which is really where simulcast belongs. >>> >>> [Duckworth, Mark] Does CLUE really need to say anything about this? >>> Isn't this separate from CLUE, and can be used with CLUE without any >>> further specification in CLUE documents? >>> >>>>> For a CLUE based solution I don't think we need to revert to MCCs. >>>>> The purpose of simulcast is to provide different encoding options >>>>> for a particular media stream. A media provider can Advertise a MC > with >> multiple encoding groups. >>>>> A media consumer if it wants to receive multiple encodings for the >>>>> same MC can simply choose multiple capture encodings e.g. >>>>> MC1/Encoding1 >>>>> MC1/Encoding2 etc. >>> >>> [Duckworth, Mark] Yes, a media provider can support multiple encodings >>> for the same MC, and a consumer can choose to configure multiple >>> encodings for the same MC. You don't even need multiple encoding >>> groups to do this, you can do it with just one group that contains > multiple >> encodings. >>> >>>> [Roni Even] How does the media consumer know that these are >>>> alternatives of a simulcast stream and know how many can be used at the >> same time. >>> >>> [Duckworth, Mark] By the MC attribute "max capture encodings". Any >>> encodings in the MC's encoding groups can be configured for a >>> particular MC, simultaneously, up to the value of "max capture > encodings". >>> >>>> You also lose here the option of the total BW that is an encoding group >> attribute. >>> >>> [Duckworth, Mark] You can still use that by advertising an MC with a >>> single encoding group, with multiple encodings in the group. >>> >>>> All these means that we need some changes to CLUE and we can look at >>>> what will make the best solution using MCs or MMCs. >>> >>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all >>> this is already supported. >>> >>>> Still the question is if we say that we will use the SDP based >>>> solution even though it is not a WG draft, having it as a normative >>>> reference will delay the publication of the CLUE draft >>>> >>>>> >>>>> Regards, Christian >>>>> >>>>> On 22/10/2014 8:00 AM, Roni Even wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> During our weekly design team meeting we discussed simulcast >>>>>> support in CLUE. >>>>>> >>>>>> Here is my take on the options, my description may not be accurate >>>>>> and the purpose here is to continue the discussion allowing us to >>>>>> have a better view of the options. >>>>>> >>>>>> Looking at the state of simulcast support in other WGs, there is an >>>>>> individual draft >>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-0 >>>>>> 4 that being discussed. The proposed solution is based on the >>>>>> unified plan where all encoded streams composing alternatives of a >>>>>> simulcast stream are in the same m-line. The alternatives are >>>>>> described using an SDP media level attribute "a=simulcast". This >>>>>> attribute is not defined for SDP session level. >>>>>> >>>>>> The first question we had is if we should base CLUE simulcast >>>>>> support on this individual draft based on CLUE timeline or try to >>>>>> define a different multicast solution at the CLUE protocol level. >>>>>> >>>>>> If we base our solution on the avtcore-rtp-simulcast-04 document >>>>>> the advertisement will include an individual encoding that will >>>>>> relate to optional multiple simulcast encoding and the configure >>>>>> will select such encoding. The actual number of different stream >>>>>> that will compose the simulcast stream will be negotiated using >>>>>> Offer/Answer as described in the above document. The risk here is >>>>>> that this is an individual draft and we may need to review the CLUE >>>>>> support if it changes. The advantage is that we will have simulcast >>>>>> the same for CLUE and non-CLUE systems. >>>>>> >>>>>> The other option for simulcast support in the CLUE protocol can be >>>>>> based on having separate Media Capture for each of the different >>>>>> simulcast encoding and use MCC to compose the simulcast alternatives. >>>>>> We will need some way to escribe that this MCC is for simulcast >>>>>> description and to provide the actual allowed individual encodes >>>>>> combinations for the Configuration by the consumer. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Roni >>> >>> _______________________________________________ >>> 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 Oct 26 15:00:16 2014 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 91A6B1A1AB0 for ; Sun, 26 Oct 2014 15:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 4Z-z6XiQDsDS for ; Sun, 26 Oct 2014 15:00:13 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA55B1A1AAF for ; Sun, 26 Oct 2014 15:00:12 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id f15so3775541lbj.27 for ; Sun, 26 Oct 2014 15:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=IqpttVdvStW47jXMfu6OyqsbItTlWVSncfsOvGIoIGc=; b=kstkU0gcVHBvLzJsDYy00U85+N3UFgnO4dDu9GNzgDd7swvv2gV7oLMx27hXbUGzvg REJAEBsiXXM8fyoZsRM7zZLsUWDHZzK5SARUMfT/x4M5K6u55o5YhrLoXv3xsCpj/z/N VI4jomt5FNmegneRo02odI5cmRFgzntFbVtSdy/k7ZJj+JP0KYk9sPcRRnH4qoWfxI0f axjFtPKyPHIe7cOTNH9d6/q7sjf5WSnDUPO0e+mQh4ZQfYAAhfgWGuTaa8h04rIeU32N EMG7/7Ywrfxp7PlZ+tjCzE5+tLdPGZwCxMYKv4EeFukU2f6RG32dgZ6tUXZlVqbl+1J5 Upcw== X-Received: by 10.112.12.35 with SMTP id v3mr19248321lbb.80.1414360810945; Sun, 26 Oct 2014 15:00:10 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id vr7sm2139342lbb.21.2014.10.26.15.00.08 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Oct 2014 15:00:10 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> In-Reply-To: <544D68BB.9060701@alum.mit.edu> Date: Mon, 27 Oct 2014 00:00:06 +0200 Message-ID: <06c301cff168$35ac97b0$a105c710$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczE5vAqnLA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xrTH8pm4Rn9qzY6yRcbNvakqZ0Q Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 22:00:15 -0000 Paul, How does the consumer know that he can configure an MC with two encodings, and which of the encodings are allowed to co-exist? Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 26 October, 2014 11:34 PM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > On 10/25/14 10:53 AM, Roni Even wrote: > > Hi Paul, > > Inline > > Roni > > > >> -----Original Message----- > >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 24 October, 2014 7:57 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> I agree with Mark here. > >> > >> Consider a plausible use case in clue: > >> > >> The advertiser has a number of captures, and has a number of encoders. > >> It can create an encoding group with all the encoders in it - some do > > hi-res > >> video, some do small videos. It puts all of those in an encoding > >> group and associates all the captures with that group. > >> > >> A "normal" consumer might configure a few of the captures with the > >> hi-res encodings, and some of the other captures with the small > >> encodings. There would be no simulcast in this case. > >> > >> Some other consumer (e.g., an MCC) may decide it wants one of the > >> captures in both big and small versions of one of the MCCs. It can > >> simply do an appropriate configuration and get that. Now we have > >> *simulcast*! The advertiser didn't have to do anything special - > >> didn't have to think about simulcast at all. > > [Roni Even] How does the consumer know that these MCs are different > > potential encodings of the same source. > > Marks, suggested different encoding group for each encoding so he can > > advertise MC1 with ENC1 and ENC2, in this case the encoding groups > > will represent different encoding parameters but will need to be > > defined accordingly, for example one encoding group that has CIF > > resolutions and the other with only HD resolutions > > This works when the advertisement assigns the capture to an encoding group > containing multiple encodings. When the consumer configures the same > encoding twice, using different encodings from the encoding group, then he > knows - by definition - they are simulcasts. > > Thanks, > Paul > > >> If an advertiser *wants* to use > >> draft-westerlund-avtcore-rtp-simulcast > >> then I see no reason to prevent that. But I would hate to force that > > (especially > >> since it isn't approved yet). > >> > >> Thanks, > >> Paul > >> > >> On 10/24/14 9:47 AM, Duckworth, Mark wrote: > >>> Hello Roni and Christian, > >>> > >>> I believe CLUE already supports simulcast today, basically as > >>> Christian > >> describes. > >>> > >>> More below. > >>> > >>> (trying to use both the "correct indentation with > > symbols", and > >>> also marking comments with my name :-) > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > >>>> Sent: Friday, October 24, 2014 8:19 AM > >>>> To: 'Christian Groves'; clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> Hi Christian, > >>>> Inline > >>>> Roni > >>>> > >>>>> -----Original Message----- > >>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>>>> Groves > >>>>> Sent: 24 October, 2014 4:59 AM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>> > >>>>> Hello Roni, > >>>>> > >>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>>>> >>>>> -0 > >>>>> 4> seems like the most straight forward approach as it keeps > >>>>> 4> things > >>>>> at the encoding level, which is really where simulcast belongs. > >>> > >>> [Duckworth, Mark] Does CLUE really need to say anything about this? > >>> Isn't this separate from CLUE, and can be used with CLUE without any > >>> further specification in CLUE documents? > >>> > >>>>> For a CLUE based solution I don't think we need to revert to MCCs. > >>>>> The purpose of simulcast is to provide different encoding options > >>>>> for a particular media stream. A media provider can Advertise a MC > > with > >> multiple encoding groups. > >>>>> A media consumer if it wants to receive multiple encodings for the > >>>>> same MC can simply choose multiple capture encodings e.g. > >>>>> MC1/Encoding1 > >>>>> MC1/Encoding2 etc. > >>> > >>> [Duckworth, Mark] Yes, a media provider can support multiple > >>> encodings for the same MC, and a consumer can choose to configure > >>> multiple encodings for the same MC. You don't even need multiple > >>> encoding groups to do this, you can do it with just one group that > >>> contains > > multiple > >> encodings. > >>> > >>>> [Roni Even] How does the media consumer know that these are > >>>> alternatives of a simulcast stream and know how many can be used at > >>>> the > >> same time. > >>> > >>> [Duckworth, Mark] By the MC attribute "max capture encodings". Any > >>> encodings in the MC's encoding groups can be configured for a > >>> particular MC, simultaneously, up to the value of "max capture > > encodings". > >>> > >>>> You also lose here the option of the total BW that is an encoding > >>>> group > >> attribute. > >>> > >>> [Duckworth, Mark] You can still use that by advertising an MC with a > >>> single encoding group, with multiple encodings in the group. > >>> > >>>> All these means that we need some changes to CLUE and we can look > >>>> at what will make the best solution using MCs or MMCs. > >>> > >>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all > >>> this is already supported. > >>> > >>>> Still the question is if we say that we will use the SDP based > >>>> solution even though it is not a WG draft, having it as a normative > >>>> reference will delay the publication of the CLUE draft > >>>> > >>>>> > >>>>> Regards, Christian > >>>>> > >>>>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> During our weekly design team meeting we discussed simulcast > >>>>>> support in CLUE. > >>>>>> > >>>>>> Here is my take on the options, my description may not be > >>>>>> accurate and the purpose here is to continue the discussion > >>>>>> allowing us to have a better view of the options. > >>>>>> > >>>>>> Looking at the state of simulcast support in other WGs, there is > >>>>>> an individual draft > >>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast > >>>>>> -0 > >>>>>> 4 that being discussed. The proposed solution is based on the > >>>>>> unified plan where all encoded streams composing alternatives of > >>>>>> a simulcast stream are in the same m-line. The alternatives are > >>>>>> described using an SDP media level attribute "a=simulcast". This > >>>>>> attribute is not defined for SDP session level. > >>>>>> > >>>>>> The first question we had is if we should base CLUE simulcast > >>>>>> support on this individual draft based on CLUE timeline or try to > >>>>>> define a different multicast solution at the CLUE protocol level. > >>>>>> > >>>>>> If we base our solution on the avtcore-rtp-simulcast-04 document > >>>>>> the advertisement will include an individual encoding that will > >>>>>> relate to optional multiple simulcast encoding and the configure > >>>>>> will select such encoding. The actual number of different stream > >>>>>> that will compose the simulcast stream will be negotiated using > >>>>>> Offer/Answer as described in the above document. The risk here is > >>>>>> that this is an individual draft and we may need to review the > >>>>>> CLUE support if it changes. The advantage is that we will have > >>>>>> simulcast the same for CLUE and non-CLUE systems. > >>>>>> > >>>>>> The other option for simulcast support in the CLUE protocol can > >>>>>> be based on having separate Media Capture for each of the > >>>>>> different simulcast encoding and use MCC to compose the simulcast > alternatives. > >>>>>> We will need some way to escribe that this MCC is for simulcast > >>>>>> description and to provide the actual allowed individual encodes > >>>>>> combinations for the Configuration by the consumer. > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Roni > >>> > >>> _______________________________________________ > >>> 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 Oct 26 16:36:55 2014 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 49C411A1B06 for ; Sun, 26 Oct 2014 16:36:54 -0700 (PDT) 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 7GRlBrpjkmzD for ; Sun, 26 Oct 2014 16:36:52 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6D01A1B04 for ; Sun, 26 Oct 2014 16:36:51 -0700 (PDT) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-02v.sys.comcast.net with comcast id 7zcp1p0025Clt1L01zcrli; Sun, 26 Oct 2014 23:36:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id 7zcq1p00N3Ge9ey01zcqx7; Sun, 26 Oct 2014 23:36:51 +0000 Message-ID: <544D8592.3010408@alum.mit.edu> Date: Sun, 26 Oct 2014 19:36:50 -0400 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: Roni Even , clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> In-Reply-To: <06c301cff168$35ac97b0$a105c710$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414366611; bh=A/4iYhIa+fs5mKqMEl5SQPxrG/0c+s0VofKBkv/e5y0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=i44sMH3+bg1hgdBQrDkCuMfmqlywOxHA5Ou+qEooAeOCsemXEOYjpC48dw1kCJDEV wxSvuuEk9yp+4ETOeLOqBNQkmXlAtkBtT7y1Hwa9eciLiVsXgn/2mr4acML04ONg0g mTa1VxGEfTJXfOkgPKrZwmmPwge6cwK2xJukQOGbLdYPCV1rNzFvfyhJ1R124aOuY+ Y5whLvkduC3kJy50bv87b0cZog58VQimB1x+QA+H+uqLJI7AHdiCV2w1D1DpCXjnb9 x5vspzchka+RZ9dCMNnXCa09f4WE/3JMnMgPxzSErhb5HOpT1ilWJwrSwFs2F6Ss/c c8lPdV8mZ6Fiw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lW3n0Qg5LzFo9HocJFR-fkp2iHQ Subject: Re: [clue] CLUE and Simulcast - ticket #47 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 23:36:54 -0000 On 10/26/14 6:00 PM, Roni Even wrote: > Paul, > How does the consumer know that he can configure an MC with two encodings, > and which of the encodings are allowed to co-exist? Look at the data model definition of a capture. It has a field . That says how many simultaneous encodings of the capture are allowed. So, if the encoding group for the capture includes more than one encoding, and maxCaptureEncodings is greater than one, then the consumer can configure simulcast. Thanks, Paul > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 26 October, 2014 11:34 PM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> On 10/25/14 10:53 AM, Roni Even wrote: >>> Hi Paul, >>> Inline >>> Roni >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 24 October, 2014 7:57 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> I agree with Mark here. >>>> >>>> Consider a plausible use case in clue: >>>> >>>> The advertiser has a number of captures, and has a number of encoders. >>>> It can create an encoding group with all the encoders in it - some do >>> hi-res >>>> video, some do small videos. It puts all of those in an encoding >>>> group and associates all the captures with that group. >>>> >>>> A "normal" consumer might configure a few of the captures with the >>>> hi-res encodings, and some of the other captures with the small >>>> encodings. There would be no simulcast in this case. >>>> >>>> Some other consumer (e.g., an MCC) may decide it wants one of the >>>> captures in both big and small versions of one of the MCCs. It can >>>> simply do an appropriate configuration and get that. Now we have >>>> *simulcast*! The advertiser didn't have to do anything special - >>>> didn't have to think about simulcast at all. >>> [Roni Even] How does the consumer know that these MCs are different >>> potential encodings of the same source. >>> Marks, suggested different encoding group for each encoding so he can >>> advertise MC1 with ENC1 and ENC2, in this case the encoding groups >>> will represent different encoding parameters but will need to be >>> defined accordingly, for example one encoding group that has CIF >>> resolutions and the other with only HD resolutions >> >> This works when the advertisement assigns the capture to an encoding group >> containing multiple encodings. When the consumer configures the same >> encoding twice, using different encodings from the encoding group, then he >> knows - by definition - they are simulcasts. >> >> Thanks, >> Paul >> >>>> If an advertiser *wants* to use >>>> draft-westerlund-avtcore-rtp-simulcast >>>> then I see no reason to prevent that. But I would hate to force that >>> (especially >>>> since it isn't approved yet). >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: >>>>> Hello Roni and Christian, >>>>> >>>>> I believe CLUE already supports simulcast today, basically as >>>>> Christian >>>> describes. >>>>> >>>>> More below. >>>>> >>>>> (trying to use both the "correct indentation with > > symbols", and >>>>> also marking comments with my name :-) >>>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>> Sent: Friday, October 24, 2014 8:19 AM >>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> Hi Christian, >>>>>> Inline >>>>>> Roni >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>> Groves >>>>>>> Sent: 24 October, 2014 4:59 AM >>>>>>> To: clue@ietf.org >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>> >>>>>>> Hello Roni, >>>>>>> >>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 >>>>>>> >>>>>> -0 >>>>>>> 4> seems like the most straight forward approach as it keeps >>>>>>> 4> things >>>>>>> at the encoding level, which is really where simulcast belongs. >>>>> >>>>> [Duckworth, Mark] Does CLUE really need to say anything about this? >>>>> Isn't this separate from CLUE, and can be used with CLUE without any >>>>> further specification in CLUE documents? >>>>> >>>>>>> For a CLUE based solution I don't think we need to revert to MCCs. >>>>>>> The purpose of simulcast is to provide different encoding options >>>>>>> for a particular media stream. A media provider can Advertise a MC >>> with >>>> multiple encoding groups. >>>>>>> A media consumer if it wants to receive multiple encodings for the >>>>>>> same MC can simply choose multiple capture encodings e.g. >>>>>>> MC1/Encoding1 >>>>>>> MC1/Encoding2 etc. >>>>> >>>>> [Duckworth, Mark] Yes, a media provider can support multiple >>>>> encodings for the same MC, and a consumer can choose to configure >>>>> multiple encodings for the same MC. You don't even need multiple >>>>> encoding groups to do this, you can do it with just one group that >>>>> contains >>> multiple >>>> encodings. >>>>> >>>>>> [Roni Even] How does the media consumer know that these are >>>>>> alternatives of a simulcast stream and know how many can be used at >>>>>> the >>>> same time. >>>>> >>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". Any >>>>> encodings in the MC's encoding groups can be configured for a >>>>> particular MC, simultaneously, up to the value of "max capture >>> encodings". >>>>> >>>>>> You also lose here the option of the total BW that is an encoding >>>>>> group >>>> attribute. >>>>> >>>>> [Duckworth, Mark] You can still use that by advertising an MC with a >>>>> single encoding group, with multiple encodings in the group. >>>>> >>>>>> All these means that we need some changes to CLUE and we can look >>>>>> at what will make the best solution using MCs or MMCs. >>>>> >>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all >>>>> this is already supported. >>>>> >>>>>> Still the question is if we say that we will use the SDP based >>>>>> solution even though it is not a WG draft, having it as a normative >>>>>> reference will delay the publication of the CLUE draft >>>>>> >>>>>>> >>>>>>> Regards, Christian >>>>>>> >>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> During our weekly design team meeting we discussed simulcast >>>>>>>> support in CLUE. >>>>>>>> >>>>>>>> Here is my take on the options, my description may not be >>>>>>>> accurate and the purpose here is to continue the discussion >>>>>>>> allowing us to have a better view of the options. >>>>>>>> >>>>>>>> Looking at the state of simulcast support in other WGs, there is >>>>>>>> an individual draft >>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast >>>>>>>> -0 >>>>>>>> 4 that being discussed. The proposed solution is based on the >>>>>>>> unified plan where all encoded streams composing alternatives of >>>>>>>> a simulcast stream are in the same m-line. The alternatives are >>>>>>>> described using an SDP media level attribute "a=simulcast". This >>>>>>>> attribute is not defined for SDP session level. >>>>>>>> >>>>>>>> The first question we had is if we should base CLUE simulcast >>>>>>>> support on this individual draft based on CLUE timeline or try to >>>>>>>> define a different multicast solution at the CLUE protocol level. >>>>>>>> >>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 document >>>>>>>> the advertisement will include an individual encoding that will >>>>>>>> relate to optional multiple simulcast encoding and the configure >>>>>>>> will select such encoding. The actual number of different stream >>>>>>>> that will compose the simulcast stream will be negotiated using >>>>>>>> Offer/Answer as described in the above document. The risk here is >>>>>>>> that this is an individual draft and we may need to review the >>>>>>>> CLUE support if it changes. The advantage is that we will have >>>>>>>> simulcast the same for CLUE and non-CLUE systems. >>>>>>>> >>>>>>>> The other option for simulcast support in the CLUE protocol can >>>>>>>> be based on having separate Media Capture for each of the >>>>>>>> different simulcast encoding and use MCC to compose the simulcast >> alternatives. >>>>>>>> We will need some way to escribe that this MCC is for simulcast >>>>>>>> description and to provide the actual allowed individual encodes >>>>>>>> combinations for the Configuration by the consumer. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Roni >>>>> >>>>> _______________________________________________ >>>>> 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 Oct 26 21:54:23 2014 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 984511A8985 for ; Sun, 26 Oct 2014 21:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 vvCwvY8F1-3R for ; Sun, 26 Oct 2014 21:54:17 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8C61A8749 for ; Sun, 26 Oct 2014 21:54:16 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id h11so3269996wiw.14 for ; Sun, 26 Oct 2014 21:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=uENy21/ljSMhhe9CxQAOO9vVTYgBmYoX5W+TSa6dTnA=; b=fk1jOmk0HZhDwz+8Rm4DFRqBZH0q45BXW2/23FyIRNwf/8oNefVn4omPufR1AKiVh4 DJG2PeKyrL8xBOE1tAXhxyg4pl4fq9AXBcTPtTovQQ5gTL2etd9ioBrg0TTRsifW+s0G 6SJtQ+lDxsCBX9ydL08EDlmjSoPK/CIN7SI/CHQHeUKasPmy3jdkGvP2Avbq/t3FSwrH GIjX8uLtlC4Uv6ZwbFNIuSt3wZS0tpXAC/D2YsrvwIuGTvZeGHWG6T02ooWg5ZUsAmUi o/hWPHLknlwpBfS9p9j2sCwVT6fSfm9eR797TFLaSNkDBAzR8JSXFVNM0gjbOuWQkHoe A6mg== X-Received: by 10.194.23.104 with SMTP id l8mr19338125wjf.26.1414385655352; Sun, 26 Oct 2014 21:54:15 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id ex6sm14238898wjb.20.2014.10.26.21.54.13 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 26 Oct 2014 21:54:14 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> In-Reply-To: <544D8592.3010408@alum.mit.edu> Date: Mon, 27 Oct 2014 06:54:11 +0200 Message-ID: <06d201cff1a2$0dee22e0$29ca68a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZCbm9P/kA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a8j2ZBqYVOi6nfx4sQHzYDMiwvg Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 27 Oct 2014 04:54:20 -0000 Hi Paul, That was the first part of the question, now assume that you have an encoding group of 5 individual encoding and maxCaptuerEncodings is 3, are all combinations OK? The AVTcore draft has a specific definition of the simulcast structure that allows you to define the allowed combinations Do we say that each capture belongs to a separate encoding group in which case it is not an encoding group but a multicast group Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 27 October, 2014 1:37 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > On 10/26/14 6:00 PM, Roni Even wrote: > > Paul, > > How does the consumer know that he can configure an MC with two > > encodings, and which of the encodings are allowed to co-exist? > > Look at the data model definition of a capture. It has a field > . That says how many simultaneous encodings of the > capture are allowed. > > So, if the encoding group for the capture includes more than one encoding, and > maxCaptureEncodings is greater than one, then the consumer can configure > simulcast. > > Thanks, > Paul > > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 26 October, 2014 11:34 PM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> On 10/25/14 10:53 AM, Roni Even wrote: > >>> Hi Paul, > >>> Inline > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: 24 October, 2014 7:57 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> I agree with Mark here. > >>>> > >>>> Consider a plausible use case in clue: > >>>> > >>>> The advertiser has a number of captures, and has a number of encoders. > >>>> It can create an encoding group with all the encoders in it - some > >>>> do > >>> hi-res > >>>> video, some do small videos. It puts all of those in an encoding > >>>> group and associates all the captures with that group. > >>>> > >>>> A "normal" consumer might configure a few of the captures with the > >>>> hi-res encodings, and some of the other captures with the small > >>>> encodings. There would be no simulcast in this case. > >>>> > >>>> Some other consumer (e.g., an MCC) may decide it wants one of the > >>>> captures in both big and small versions of one of the MCCs. It can > >>>> simply do an appropriate configuration and get that. Now we have > >>>> *simulcast*! The advertiser didn't have to do anything special - > >>>> didn't have to think about simulcast at all. > >>> [Roni Even] How does the consumer know that these MCs are different > >>> potential encodings of the same source. > >>> Marks, suggested different encoding group for each encoding so he > >>> can advertise MC1 with ENC1 and ENC2, in this case the encoding > >>> groups will represent different encoding parameters but will need to > >>> be defined accordingly, for example one encoding group that has CIF > >>> resolutions and the other with only HD resolutions > >> > >> This works when the advertisement assigns the capture to an encoding > >> group containing multiple encodings. When the consumer configures the > >> same encoding twice, using different encodings from the encoding > >> group, then he knows - by definition - they are simulcasts. > >> > >> Thanks, > >> Paul > >> > >>>> If an advertiser *wants* to use > >>>> draft-westerlund-avtcore-rtp-simulcast > >>>> then I see no reason to prevent that. But I would hate to force > >>>> that > >>> (especially > >>>> since it isn't approved yet). > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: > >>>>> Hello Roni and Christian, > >>>>> > >>>>> I believe CLUE already supports simulcast today, basically as > >>>>> Christian > >>>> describes. > >>>>> > >>>>> More below. > >>>>> > >>>>> (trying to use both the "correct indentation with > > symbols", > >>>>> and also marking comments with my name :-) > >>>>> > >>>>> Mark > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > >>>>>> Sent: Friday, October 24, 2014 8:19 AM > >>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> Hi Christian, > >>>>>> Inline > >>>>>> Roni > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>>>>>> Groves > >>>>>>> Sent: 24 October, 2014 4:59 AM > >>>>>>> To: clue@ietf.org > >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>> > >>>>>>> Hello Roni, > >>>>>>> > >>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>>>>>> >>>>>>> st > >>>>>>> -0 > >>>>>>> 4> seems like the most straight forward approach as it keeps > >>>>>>> 4> things > >>>>>>> at the encoding level, which is really where simulcast belongs. > >>>>> > >>>>> [Duckworth, Mark] Does CLUE really need to say anything about this? > >>>>> Isn't this separate from CLUE, and can be used with CLUE without > >>>>> any further specification in CLUE documents? > >>>>> > >>>>>>> For a CLUE based solution I don't think we need to revert to MCCs. > >>>>>>> The purpose of simulcast is to provide different encoding > >>>>>>> options for a particular media stream. A media provider can > >>>>>>> Advertise a MC > >>> with > >>>> multiple encoding groups. > >>>>>>> A media consumer if it wants to receive multiple encodings for > >>>>>>> the same MC can simply choose multiple capture encodings e.g. > >>>>>>> MC1/Encoding1 > >>>>>>> MC1/Encoding2 etc. > >>>>> > >>>>> [Duckworth, Mark] Yes, a media provider can support multiple > >>>>> encodings for the same MC, and a consumer can choose to configure > >>>>> multiple encodings for the same MC. You don't even need multiple > >>>>> encoding groups to do this, you can do it with just one group that > >>>>> contains > >>> multiple > >>>> encodings. > >>>>> > >>>>>> [Roni Even] How does the media consumer know that these are > >>>>>> alternatives of a simulcast stream and know how many can be used > >>>>>> at the > >>>> same time. > >>>>> > >>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". > >>>>> Any encodings in the MC's encoding groups can be configured for a > >>>>> particular MC, simultaneously, up to the value of "max capture > >>> encodings". > >>>>> > >>>>>> You also lose here the option of the total BW that is an encoding > >>>>>> group > >>>> attribute. > >>>>> > >>>>> [Duckworth, Mark] You can still use that by advertising an MC with > >>>>> a single encoding group, with multiple encodings in the group. > >>>>> > >>>>>> All these means that we need some changes to CLUE and we can look > >>>>>> at what will make the best solution using MCs or MMCs. > >>>>> > >>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all > >>>>> this is already supported. > >>>>> > >>>>>> Still the question is if we say that we will use the SDP based > >>>>>> solution even though it is not a WG draft, having it as a > >>>>>> normative reference will delay the publication of the CLUE draft > >>>>>> > >>>>>>> > >>>>>>> Regards, Christian > >>>>>>> > >>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> During our weekly design team meeting we discussed simulcast > >>>>>>>> support in CLUE. > >>>>>>>> > >>>>>>>> Here is my take on the options, my description may not be > >>>>>>>> accurate and the purpose here is to continue the discussion > >>>>>>>> allowing us to have a better view of the options. > >>>>>>>> > >>>>>>>> Looking at the state of simulcast support in other WGs, there > >>>>>>>> is an individual draft > >>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulca > >>>>>>>> st > >>>>>>>> -0 > >>>>>>>> 4 that being discussed. The proposed solution is based on the > >>>>>>>> unified plan where all encoded streams composing alternatives > >>>>>>>> of a simulcast stream are in the same m-line. The alternatives > >>>>>>>> are described using an SDP media level attribute "a=simulcast". > >>>>>>>> This attribute is not defined for SDP session level. > >>>>>>>> > >>>>>>>> The first question we had is if we should base CLUE simulcast > >>>>>>>> support on this individual draft based on CLUE timeline or try > >>>>>>>> to define a different multicast solution at the CLUE protocol level. > >>>>>>>> > >>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 > >>>>>>>> document the advertisement will include an individual encoding > >>>>>>>> that will relate to optional multiple simulcast encoding and > >>>>>>>> the configure will select such encoding. The actual number of > >>>>>>>> different stream that will compose the simulcast stream will be > >>>>>>>> negotiated using Offer/Answer as described in the above > >>>>>>>> document. The risk here is that this is an individual draft and > >>>>>>>> we may need to review the CLUE support if it changes. The > >>>>>>>> advantage is that we will have simulcast the same for CLUE and non- > CLUE systems. > >>>>>>>> > >>>>>>>> The other option for simulcast support in the CLUE protocol can > >>>>>>>> be based on having separate Media Capture for each of the > >>>>>>>> different simulcast encoding and use MCC to compose the > >>>>>>>> simulcast > >> alternatives. > >>>>>>>> We will need some way to escribe that this MCC is for simulcast > >>>>>>>> description and to provide the actual allowed individual > >>>>>>>> encodes combinations for the Configuration by the consumer. > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> > >>>>>>>> Roni > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Oct 27 03:20:48 2014 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 43AFB1A903A for ; Mon, 27 Oct 2014 03:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 M89cUotlEOoV for ; Mon, 27 Oct 2014 03:20:39 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFE931A6F7D for ; Mon, 27 Oct 2014 03:20:38 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id n3so5945522wiv.2 for ; Mon, 27 Oct 2014 03:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=qEoc7hq/Ttnd+sss9AyZJaXrgYlyqO4yCJjptuLzgNw=; b=fmqDtqKB8FFEiv7h0bSzWi2p0TnZ3jStQI+4RdDPCBtTn8wpTmTdL48+roO6QQ7v8+ bSaJrp3Ai31hUeVQeet6TaeLq94/xujvWXDuJ1cVm7DNunXTqmA7d+QQ3cPr7RnEPBt8 5P6ovqRKadkDKF2xGzqNRRuMUv6ZHmYYfFM64PEirWARjR4yj35B/wydvA5+5s7+vfBg MHB01q8JjkUPpp+YLuGRCkX+ZLAt9ghRFkEDjd+5XQhTi6DWTstJ9VovPGeFiIixA0TY 9arfpael7Ty99Dmp9i9dlC2e2Rha5CmZdzmnPGmv79hPDp+r7OzMGxiargOlHClRrXGG /nRQ== X-Received: by 10.194.93.194 with SMTP id cw2mr1496961wjb.112.1414405237543; Mon, 27 Oct 2014 03:20:37 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id gw6sm11359222wib.8.2014.10.27.03.20.34 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Oct 2014 03:20:36 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> In-Reply-To: <544D8592.3010408@alum.mit.edu> Date: Mon, 27 Oct 2014 12:20:31 +0200 Message-ID: <06f701cff1cf$a57c1310$f0743930$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtvftecBcvTE3sB/lK8M6c3I3e2AH3s1nrAiXG47AA3KIXRgH0t/LAAONJoDkBAxczEwHhC5T4AsgMzZCbnCmjAA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/CckhvDxBWFZABi7rluouFjNSpLQ Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 27 Oct 2014 10:20:45 -0000 Hi Paul, If we want to be able to differentiate between simulcast and switched capture, for example if we have a three camera system that can send three MCs each with two encodings (simulcast) and a switched capture (loudest speaker or two loudest speakers out of three) using the same simulcast option for the each MC currently sent. In this case we can have an MC with two encodings and an MCC with the three MCs. This will require us to clarify that having multiple individual encodings in MC is simulcast and not switched and in MCC it is switched and not simulcast. Now what may complicate the advertisement is if the individual MCs can simulcast two encodings while the MCC (switched) is only with one encoding, this may require different MCs for MCC or individual MCs case As for the data model draft, the example https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-26 may be confusing. It has for VC0, VC1 and VC2 2 while the EG0 has only three encID so if it was meant to support simulcast it will require six encID for Scene View SE1. Roni > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 27 October, 2014 1:37 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] CLUE and Simulcast - ticket #47 > > On 10/26/14 6:00 PM, Roni Even wrote: > > Paul, > > How does the consumer know that he can configure an MC with two > > encodings, and which of the encodings are allowed to co-exist? > > Look at the data model definition of a capture. It has a field > . That says how many simultaneous encodings of the > capture are allowed. > > So, if the encoding group for the capture includes more than one encoding, and > maxCaptureEncodings is greater than one, then the consumer can configure > simulcast. > > Thanks, > Paul > > > > Roni > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: 26 October, 2014 11:34 PM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >> > >> On 10/25/14 10:53 AM, Roni Even wrote: > >>> Hi Paul, > >>> Inline > >>> Roni > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: 24 October, 2014 7:57 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>> > >>>> I agree with Mark here. > >>>> > >>>> Consider a plausible use case in clue: > >>>> > >>>> The advertiser has a number of captures, and has a number of encoders. > >>>> It can create an encoding group with all the encoders in it - some > >>>> do > >>> hi-res > >>>> video, some do small videos. It puts all of those in an encoding > >>>> group and associates all the captures with that group. > >>>> > >>>> A "normal" consumer might configure a few of the captures with the > >>>> hi-res encodings, and some of the other captures with the small > >>>> encodings. There would be no simulcast in this case. > >>>> > >>>> Some other consumer (e.g., an MCC) may decide it wants one of the > >>>> captures in both big and small versions of one of the MCCs. It can > >>>> simply do an appropriate configuration and get that. Now we have > >>>> *simulcast*! The advertiser didn't have to do anything special - > >>>> didn't have to think about simulcast at all. > >>> [Roni Even] How does the consumer know that these MCs are different > >>> potential encodings of the same source. > >>> Marks, suggested different encoding group for each encoding so he > >>> can advertise MC1 with ENC1 and ENC2, in this case the encoding > >>> groups will represent different encoding parameters but will need to > >>> be defined accordingly, for example one encoding group that has CIF > >>> resolutions and the other with only HD resolutions > >> > >> This works when the advertisement assigns the capture to an encoding > >> group containing multiple encodings. When the consumer configures the > >> same encoding twice, using different encodings from the encoding > >> group, then he knows - by definition - they are simulcasts. > >> > >> Thanks, > >> Paul > >> > >>>> If an advertiser *wants* to use > >>>> draft-westerlund-avtcore-rtp-simulcast > >>>> then I see no reason to prevent that. But I would hate to force > >>>> that > >>> (especially > >>>> since it isn't approved yet). > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: > >>>>> Hello Roni and Christian, > >>>>> > >>>>> I believe CLUE already supports simulcast today, basically as > >>>>> Christian > >>>> describes. > >>>>> > >>>>> More below. > >>>>> > >>>>> (trying to use both the "correct indentation with > > symbols", > >>>>> and also marking comments with my name :-) > >>>>> > >>>>> Mark > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > >>>>>> Sent: Friday, October 24, 2014 8:19 AM > >>>>>> To: 'Christian Groves'; clue@ietf.org > >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>> > >>>>>> Hi Christian, > >>>>>> Inline > >>>>>> Roni > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > >>>>>>> Groves > >>>>>>> Sent: 24 October, 2014 4:59 AM > >>>>>>> To: clue@ietf.org > >>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 > >>>>>>> > >>>>>>> Hello Roni, > >>>>>>> > >>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 > >>>>>>> >>>>>>> st > >>>>>>> -0 > >>>>>>> 4> seems like the most straight forward approach as it keeps > >>>>>>> 4> things > >>>>>>> at the encoding level, which is really where simulcast belongs. > >>>>> > >>>>> [Duckworth, Mark] Does CLUE really need to say anything about this? > >>>>> Isn't this separate from CLUE, and can be used with CLUE without > >>>>> any further specification in CLUE documents? > >>>>> > >>>>>>> For a CLUE based solution I don't think we need to revert to MCCs. > >>>>>>> The purpose of simulcast is to provide different encoding > >>>>>>> options for a particular media stream. A media provider can > >>>>>>> Advertise a MC > >>> with > >>>> multiple encoding groups. > >>>>>>> A media consumer if it wants to receive multiple encodings for > >>>>>>> the same MC can simply choose multiple capture encodings e.g. > >>>>>>> MC1/Encoding1 > >>>>>>> MC1/Encoding2 etc. > >>>>> > >>>>> [Duckworth, Mark] Yes, a media provider can support multiple > >>>>> encodings for the same MC, and a consumer can choose to configure > >>>>> multiple encodings for the same MC. You don't even need multiple > >>>>> encoding groups to do this, you can do it with just one group that > >>>>> contains > >>> multiple > >>>> encodings. > >>>>> > >>>>>> [Roni Even] How does the media consumer know that these are > >>>>>> alternatives of a simulcast stream and know how many can be used > >>>>>> at the > >>>> same time. > >>>>> > >>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". > >>>>> Any encodings in the MC's encoding groups can be configured for a > >>>>> particular MC, simultaneously, up to the value of "max capture > >>> encodings". > >>>>> > >>>>>> You also lose here the option of the total BW that is an encoding > >>>>>> group > >>>> attribute. > >>>>> > >>>>> [Duckworth, Mark] You can still use that by advertising an MC with > >>>>> a single encoding group, with multiple encodings in the group. > >>>>> > >>>>>> All these means that we need some changes to CLUE and we can look > >>>>>> at what will make the best solution using MCs or MMCs. > >>>>> > >>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all > >>>>> this is already supported. > >>>>> > >>>>>> Still the question is if we say that we will use the SDP based > >>>>>> solution even though it is not a WG draft, having it as a > >>>>>> normative reference will delay the publication of the CLUE draft > >>>>>> > >>>>>>> > >>>>>>> Regards, Christian > >>>>>>> > >>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> During our weekly design team meeting we discussed simulcast > >>>>>>>> support in CLUE. > >>>>>>>> > >>>>>>>> Here is my take on the options, my description may not be > >>>>>>>> accurate and the purpose here is to continue the discussion > >>>>>>>> allowing us to have a better view of the options. > >>>>>>>> > >>>>>>>> Looking at the state of simulcast support in other WGs, there > >>>>>>>> is an individual draft > >>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulca > >>>>>>>> st > >>>>>>>> -0 > >>>>>>>> 4 that being discussed. The proposed solution is based on the > >>>>>>>> unified plan where all encoded streams composing alternatives > >>>>>>>> of a simulcast stream are in the same m-line. The alternatives > >>>>>>>> are described using an SDP media level attribute "a=simulcast". > >>>>>>>> This attribute is not defined for SDP session level. > >>>>>>>> > >>>>>>>> The first question we had is if we should base CLUE simulcast > >>>>>>>> support on this individual draft based on CLUE timeline or try > >>>>>>>> to define a different multicast solution at the CLUE protocol level. > >>>>>>>> > >>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 > >>>>>>>> document the advertisement will include an individual encoding > >>>>>>>> that will relate to optional multiple simulcast encoding and > >>>>>>>> the configure will select such encoding. The actual number of > >>>>>>>> different stream that will compose the simulcast stream will be > >>>>>>>> negotiated using Offer/Answer as described in the above > >>>>>>>> document. The risk here is that this is an individual draft and > >>>>>>>> we may need to review the CLUE support if it changes. The > >>>>>>>> advantage is that we will have simulcast the same for CLUE and non- > CLUE systems. > >>>>>>>> > >>>>>>>> The other option for simulcast support in the CLUE protocol can > >>>>>>>> be based on having separate Media Capture for each of the > >>>>>>>> different simulcast encoding and use MCC to compose the > >>>>>>>> simulcast > >> alternatives. > >>>>>>>> We will need some way to escribe that this MCC is for simulcast > >>>>>>>> description and to provide the actual allowed individual > >>>>>>>> encodes combinations for the Configuration by the consumer. > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> > >>>>>>>> Roni > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Oct 27 06:03:32 2014 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 230FD1ABD38; Mon, 27 Oct 2014 06:03:17 -0700 (PDT) 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 Q6aFV11UpV1Q; Mon, 27 Oct 2014 06:03:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 566CF1A0366; Mon, 27 Oct 2014 06:03:15 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027130315.6434.28356.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 06:03:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zeBmoNHnfcObHs_F8e-F0leuMMA Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-02.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: Mon, 27 Oct 2014 13:03:17 -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-02.txt Pages : 13 Date : 2014-10-27 Abstract: This document defines how to use the WebRTC Data Channel mechanism, together with the Data Channel Establishment Protocol (DCEP) in order to establish a data channel, referred to as CLUE Data Channel, for transporting CLUE protocol messages between two CLUE entities. The document defines the SCTP considerations specific to a CLUE Data Channel, the SDP offer/answer procedures for negotiating the establishment of, and the DCEP procedures for opening, a CLUE Data Channel. Details and procedures associated with the CLUE protocol 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-02 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 Mon Oct 27 06:23:50 2014 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 986F01A8AE7 for ; Mon, 27 Oct 2014 06:23:22 -0700 (PDT) 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 yLb1ZDYO3YaS for ; Mon, 27 Oct 2014 06:23:20 -0700 (PDT) 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 414E71A8AA7 for ; Mon, 27 Oct 2014 06:23:20 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-43-544e47464aa0 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EA.9F.04081.6474E445; Mon, 27 Oct 2014 14:23:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 14:23:17 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3wAAWmcQ Date: Mon, 27 Oct 2014 13:23:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CCF6F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4CCF6FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvja6bu1+IwctXUhb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqa5qxkLpulUPF2/n6mBsVG9i5GTQ0LARGLNwTVsELaYxIV7 64FsLg4hgSOMEhd33WaFcJYwSqx40APkcHCwCVhIdP/TBmkQEVCWOLq5H6xZWMBc4sfmOSwQ cQuJ1X8uMkLYRhI/e76zg9gsAqoS8450gcV5BXwl+mZvBKsXArLXbrwONodTwE9i6v5nTCA2 I9BB30+tAbOZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/+xQtiKEu1PGxhBzmQWyJfY2y8DsUpQ 4uTMJywTGEVmIZk0C6FqFpIqiBIdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcVJu upGRXmpRZnJxcX6eXl5qySZGYPwc3PLbYAfjy+eOhxgFOBiVeHg/1PiGCLEmlhVX5h5ilOZg URLnXXhuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRg2W0LeNj9mKpsXX/SiZJLzOVJS9 5dy64x803JuvO4gG7tn++E71/6PrJt51blnlLXbQ627Vg7VBjzW9HmlN3Ct5c2FKu2qvlP2L pccvr3dd2nMiar/07YDiMGYJNzY5Foa/XAdtd7RwCjpZ/55laiH41EzdYn7B/ukFy6e1y1go p5/6WmC9T4mlOCPRUIu5qDgRAPS5ikGAAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DS3jPkwvr3BsDnyRa3usrp3c318 Subject: [clue] FW: Meaning of SHOULD support/use interleaving 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, 27 Oct 2014 13:23:22 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4CCF6FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, As agreed at the design team meeting a few weeks ago, I have sent the follo= wing e-mail to the RTCWEB list. Regards, Christer From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 27. lokakuuta 2014 15:13 To: rtcweb@ietf.org Subject: [rtcweb] Meaning of SHOULD support/use interleaving Hi, Within the CLUE WG, we had a discussion regarding the following statement i= n section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: "The support for message interleaving as defined in [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." First, it is a little unclear what "the support SHOULD be used" means. Second, does it mean that any data channel protocol (e.g CLUE) SHOULD use i= nterleaving, even if the characteristics of the protocol wouldn't require i= t? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D4CCF6FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

As agreed at the desig= n team meeting a few weeks ago, I have sent the following e-mail to the RTC= WEB list.

 

Regards,

 

Christer

 

From: rtcweb [= mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 27. lokakuuta 2014 15:13
To: rtcweb@ietf.org
Subject: [rtcweb] Meaning of SHOULD support/use interleaving

 

Hi,

 

Within the CLUE WG, we had a discussion regarding th= e following statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.t= xt:

 

“The support for = message interleaving as defined in

         &nb= sp;      [I-D.ietf-tsvwg-sctp-ndata] SHOULD be use= d.”

 

First, it is a little unclear what “the suppor= t SHOULD be used” means.

 

Second, does it mean that any data channel protocol = (e.g CLUE) SHOULD use interleaving, even if the characteristics of the prot= ocol wouldn’t require it?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D4CCF6FESESSMB209erics_-- From nobody Mon Oct 27 07:24:46 2014 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 35D571A8774 for ; Mon, 27 Oct 2014 07:24:15 -0700 (PDT) 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 MAz8E1fEztSX for ; Mon, 27 Oct 2014 07:24:14 -0700 (PDT) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E193A1A00A3 for ; Mon, 27 Oct 2014 07:24:13 -0700 (PDT) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-04v.sys.comcast.net with comcast id 8EQ01p00853iAfU01EQDAL; Mon, 27 Oct 2014 14:24:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-10v.sys.comcast.net with comcast id 8EQC1p00V3Ge9ey01EQDUj; Mon, 27 Oct 2014 14:24:13 +0000 Message-ID: <544E558C.8070209@alum.mit.edu> Date: Mon, 27 Oct 2014 10:24:12 -0400 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: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CCF6F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CCF6F@ESESSMB209.ericsson.se> 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=1414419853; bh=oZEcbQjuSbcQbquYOtmNZc7ammsJX2i2UEa7JI/g910=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RjD9+iL0jYanr4iAS5KOi9fV5lE4W8v/KtocA42GFtNjAE8LhpvhbQIkA6bYRcpH7 LWnyqVvHIOfPetuF7Bp+gPZpVrzAecHqb5x+Qvr8VQviW5pbZRb9g/NE3XCH7SZfqR WC1/9m2Shycu2WpVm6JxDCpXu+3IbFrforg9bF+Dirsw8vKIh4ckAY21V8RVaeuWW/ 5jhEqtU7hYMQoplScdGfFjwwriX0zG3ykQEh8Xq/SApTCT1WYwJQ9VBrTzXX9jOCwR mdz5egdG0WTbuSuoupZxJpMys3hfS/MD+IzREq2YjYUGzGnQPtPodNGZ0qnj49H7Lo IrgskCk4s4kxA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/69WO5i9oBDQyu84JH8vZ59Qi7Lo Subject: Re: [clue] FW: Meaning of SHOULD support/use interleaving 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, 27 Oct 2014 14:24:15 -0000 On 10/27/14 9:23 AM, Christer Holmberg wrote: > FYI, > > As agreed at the design team meeting a few weeks ago, I have sent the > following e-mail to the RTCWEB list. Thanks Christer! > Regards, > > Christer > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* 27. lokakuuta 2014 15:13 > *To:* rtcweb@ietf.org > *Subject:* [rtcweb] Meaning of SHOULD support/use interleaving > > Hi, > > Within the CLUE WG, we had a discussion regarding the following > statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: > > The support for message interleaving as defined in > > [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. > > First, it is a little unclear what the support SHOULD be used means. > > Second, does it mean that any data channel protocol (e.g CLUE) SHOULD > use interleaving, even if the characteristics of the protocol wouldnt > require it? > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Oct 27 11:29:37 2014 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 D878A1A8A64 for ; Mon, 27 Oct 2014 11:29:17 -0700 (PDT) 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 BTJvTXcUyMPH for ; Mon, 27 Oct 2014 11:29:14 -0700 (PDT) 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 2385A1ACDA8 for ; Mon, 27 Oct 2014 11:26:10 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-4d-544e8e414be8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.22.04081.14E8E445; Mon, 27 Oct 2014 19:26:09 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 19:26:08 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/x88lK6mpn4HE9TuemRholN7+6tQAHy8mw Date: Mon, 27 Oct 2014 18:26:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja5jn1+Iwfv50hb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpJzM9gLvipULFyl18DYLd3FyMEhIWAi8fVpSBcjJ5ApJnHh 3nq2LkYuDiGBI4wSK5s3MEM4SxglvnasZwVpYBOwkOj+pw3SICKgLHF0cz8biC0skCLxcOcE Noh4qsTpCVeYIGwjiQMbF7OD2CwCqhK/vu1mBrF5BXwlDm2bDFYjJBAl8eVxH1gNp0C0xLVP k8FqGIEO+n5qDVgNs4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSWLR7c9Q9ToSC3Z/YoOw tSWWLXwNtVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+n l5dasokRGA8Ht/w22MH48rnjIUYBDkYlHt4PNb4hQqyJZcWVuYcYpTlYlMR5F56bFywkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qB0Wyt08f/Hx4evvWQ/1zGovkzVnfKCm16oekUUXkrv9vr QIDfm5MPYuZUvNy832lnTobC3MSDXyv09yl+ufuo32vtw+K4RQIp4nX8LhtP1+1jnt++bZqC p6lSichNHZZ3qcrF+y/L1HffEuhdyefj8L1h06rSjg3xRxXdznobNXHeWGR+Okx6vhJLcUai oRZzUXEiAHt5lJ9oAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1oj3jLKvmgSFHTtFRBtYJ0XFJa0 Subject: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 27 Oct 2014 18:29:18 -0000 FYI, Keith has submitted a new version of the SDP-data-channel-neg draft. Personally I think the mechanism would be useful, but I think it would be g= ood to have a "CLUE opinion" also. Currently we only have an editor's note = saying that we may consider the mechanism depending on how it progresses. B= ut, as we know, nothing progresses by itself in IETF, so the question is wh= ether we shall say "CLUE has an interest in this mechanism, and would like = it to move forward". Regards, Christer -----Original Message----- From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of DRAGE, Keith (Ke= ith) Sent: 27 October 2014 16:39 To: mmusic@ietf.org Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mm= usic-msrp-usage-data-channel Based on the discussion on list over the last few days, I have submitted re= vised versions of the two SDP negotiation over data channel drafts as follo= ws: A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-data-channel-sdpneg Revision: 02 Title: SDP-based "SCTP over DTLS" data channel negotiation Document date: 2014-10-27 Group: Individual Submission Pages: 22 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data= -channel-sdpneg-02.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-ch= annel-sdpneg/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-= sdpneg-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-= channel-sdpneg-02 Abstract: The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communications using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP, where each data channel might be used to transport other protocols, called sub-protocols. Data channel setup can be done using either the internal in-band band (also referred to as 'internal' for the rest of the document) WebRTC Data Channel Establishment Protocol or some external out-of-band simply referred to as 'external negotiation' in the rest of the document . This document specifies how the SDP offer/answer exchange can be used to achieve such an external negotiation. Even though data channels are designed for RTCWeb use initially they may be used by other protocols like, but not limited to, the CLUE protocol. This document is intended to be used wherever data channels are used. A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt has been successfully submitted by Keith Drage and posted to the IETF repos= itory. Name: draft-ejzak-mmusic-msrp-usage-data-channel Revision: 01 Title: MSRP over SCTP/DTLS data channels Document date: 2014-10-27 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp= -usage-data-channel-01.txt Status: https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-us= age-data-channel/ Htmlized: http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-da= ta-channel-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-= usage-data-channel-01 Abstract: This document specifies how the Message Session Relay Protocol (MSRP) can be instantiated as a data channel sub-protocol, using the the SDP offer/answer exchange-based external negotiation defined in [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two MSRP over data channel endpoints), and a gateway configuration (connecting an MSRP over data channel endpoint with an MSRP over TCP endpoint). _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From nobody Mon Oct 27 12:06:36 2014 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 041C61AD013 for ; Mon, 27 Oct 2014 12:06:11 -0700 (PDT) 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 ypU2RMSyXnrJ for ; Mon, 27 Oct 2014 12:06:07 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2836A1ACFF0 for ; Mon, 27 Oct 2014 12:05:17 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so6205913lbd.20 for ; Mon, 27 Oct 2014 12:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eMiRk2QNf/ZtxVAorTrmbDeyWY9aYgTgWXQvoapq7uU=; b=DaY1OugPbu6AzxqLwRjRpE+WXx5FZSoKBhEMtxqyu97XMsGzL5VHLcVSudhxmnQlQ4 V0BoABJtfVIJ23s6kbIrs53veyK8HYDYrK4uYgAfsPZBAa8O9VJ4pFKh4Ap3JHhCQqrJ URRGX/uFsf+Z2vf38DKty/ZKv6PtaTxPAAhD2KJFqf+rp0Eg8ptjyNsBUE2Or6YZAry1 deKHrHZ14HcqnDDKkblaLoNpq8ohJa7lcfQqtJNNyi0iLNG6alrqdvKo4SSc7jhg4Mxd bbAv4LMC1GEjPJaxQTqBrfXVLAcyBVkxJ18REuuIT3Slk9mRP35b8lJmCsPqDEfQ6cWX HiwQ== MIME-Version: 1.0 X-Received: by 10.152.1.42 with SMTP id 10mr26365430laj.4.1414436716296; Mon, 27 Oct 2014 12:05:16 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Mon, 27 Oct 2014 12:05:16 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> Date: Mon, 27 Oct 2014 14:05:16 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e013c65bc083f9305066c3658 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZD9T3yMUPFGvqAVskvro8TxQwVs Cc: "clue@ietf.org" Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 27 Oct 2014 19:06:11 -0000 --089e013c65bc083f9305066c3658 Content-Type: text/plain; charset=UTF-8 When we discussed this at IETF-90, we said that we would consider it if the updated document was submitted no later than September 1st (per the minutes). Of course, that date wasn't met. My suggestion is that if there is consensus to adopt this as an MMUSIC WG deliverable, we could add a reference. BUT, I would still be concerned about delays in that work that would result in CLUE documents sitting in the RFC editor's queue waiting for that document. As an individual, considering the overall pace of the work on that document thus far, I would be quite worried about adding that as a dependency. Regards, Mary. On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > FYI, > > Keith has submitted a new version of the SDP-data-channel-neg draft. > > Personally I think the mechanism would be useful, but I think it would be > good to have a "CLUE opinion" also. Currently we only have an editor's note > saying that we may consider the mechanism depending on how it progresses. > But, as we know, nothing progresses by itself in IETF, so the question is > whether we shall say "CLUE has an interest in this mechanism, and would > like it to move forward". > > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of DRAGE, Keith > (Keith) > Sent: 27 October 2014 16:39 > To: mmusic@ietf.org > Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > Based on the discussion on list over the last few days, I have submitted > revised versions of the two SDP negotiation over data channel drafts as > follows: > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to the IETF > repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data channel setup > can be done using either the internal in-band band (also referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data channels are > designed for RTCWeb use initially they may be used by other protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to the IETF > repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01 > > Abstract: > This document specifies how the Message Session Relay Protocol (MSRP) > can be instantiated as a data channel sub-protocol, using the the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an MSRP over TCP > endpoint). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e013c65bc083f9305066c3658 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When we discussed this at IETF-90, we said that we would c= onsider it if the updated document was submitted no later than September 1s= t (per the minutes).=C2=A0 Of course, that date wasn't met.=C2=A0 My su= ggestion is that if there is consensus to adopt this as an MMUSIC WG delive= rable, we could add a reference. BUT, I would still be concerned about dela= ys in that work that would result in CLUE documents sitting in the RFC edit= or's queue waiting for that document. =C2=A0

As an i= ndividual, considering the overall pace of the work on that document thus f= ar, I would be quite worried about adding that as a dependency.

Regards,
Mary.

On Mon, Oct 27, 2014 at 1:26 PM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote= :
FYI,

Keith has submitted a new version of the SDP-data-channel-neg draft.

Personally I think the mechanism would be useful, but I think it would be g= ood to have a "CLUE opinion" also. Currently we only have an edit= or's note saying that we may consider the mechanism depending on how it= progresses. But, as we know, nothing progresses by itself in IETF, so the = question is whether we shall say "CLUE has an interest in this mechani= sm, and would like it to move forward".

Regards,

Christer


-----Original Message-----
From: mmusic [mailto:mmusic-boun= ces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: 27 October 2014 16:39
To: mmusic@ietf.org
Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mm= usic-msrp-usage-data-channel

Based on the discussion on list over the last few days, I have submitted re= vised versions of the two SDP negotiation over data channel drafts as follo= ws:

A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
has been successfully submitted by Keith Drage and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ejzak-mmusic-data-chann= el-sdpneg
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP-based "SCTP over DTLS&quo= t; data channel negotiation
Document date:=C2=A0 2014-10-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel= -sdpneg-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ie= tf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-data-channel-sdpne= g-02

Abstract:
=C2=A0 =C2=A0The Real-Time Communication in WEB-browsers (RTCWeb) working g= roup is
=C2=A0 =C2=A0charged to provide protocols to support direct interactive ric= h
=C2=A0 =C2=A0communications using audio, video, and data between two peers&= #39; web-
=C2=A0 =C2=A0browsers.=C2=A0 For the support of data communication, the RTC= Web working
=C2=A0 =C2=A0group has in particular defined the concept of bi-directional = data
=C2=A0 =C2=A0channels over SCTP, where each data channel might be used to =C2=A0 =C2=A0transport other protocols, called sub-protocols.=C2=A0 Data ch= annel setup
=C2=A0 =C2=A0can be done using either the internal in-band band (also refer= red to
=C2=A0 =C2=A0as 'internal' for the rest of the document) WebRTC Dat= a Channel
=C2=A0 =C2=A0Establishment Protocol or some external out-of-band simply ref= erred
=C2=A0 =C2=A0to as 'external negotiation' in the rest of the docume= nt . This
=C2=A0 =C2=A0document specifies how the SDP offer/answer exchange can be us= ed to
=C2=A0 =C2=A0achieve such an external negotiation.=C2=A0 Even though data c= hannels are
=C2=A0 =C2=A0designed for RTCWeb use initially they may be used by other pr= otocols
=C2=A0 =C2=A0like, but not limited to, the CLUE protocol.=C2=A0 This docume= nt is
=C2=A0 =C2=A0intended to be used wherever data channels are used.


A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
has been successfully submitted by Keith Drage and posted to the IETF repos= itory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ejzak-mmusic-msrp-usage= -data-channel
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MSRP over SCTP/DTLS data channels<= br> Document date:=C2=A0 2014-10-27
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usa= ge-data-channel-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/<= /a>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tool= s.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/rfcdiff?url2=3Ddraft-ejzak-mmusic-msrp-usage-dat= a-channel-01

Abstract:
=C2=A0 =C2=A0This document specifies how the Message Session Relay Protocol= (MSRP)
=C2=A0 =C2=A0can be instantiated as a data channel sub-protocol, using the = the SDP
=C2=A0 =C2=A0offer/answer exchange-based external negotiation defined in =C2=A0 =C2=A0[I-D.ejzak-mmusic-data-channel-sdpneg].=C2=A0 Two network conf= igurations
=C2=A0 =C2=A0are documented: a WebRTC end-to-end configuration (connecting = two
=C2=A0 =C2=A0MSRP over data channel endpoints), and a gateway configuration=
=C2=A0 =C2=A0(connecting an MSRP over data channel endpoint with an MSRP ov= er TCP
=C2=A0 =C2=A0endpoint).
_______________________________________________
mmusic mailing list
mmusic@ietf.org
= https://www.ietf.org/mailman/listinfo/mmusic

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

--089e013c65bc083f9305066c3658-- From nobody Mon Oct 27 13:18:43 2014 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 0DAE41A1A53 for ; Mon, 27 Oct 2014 13:18:15 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jc7sKaXjl8YP for ; Mon, 27 Oct 2014 13:18:12 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3571A1A51 for ; Mon, 27 Oct 2014 13:18:09 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-05v.sys.comcast.net with comcast id 8LHt1p0055AAYLo01LJ8ye; Mon, 27 Oct 2014 20:18:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id 8LHy1p0043Ge9ey01LJ7jY; Mon, 27 Oct 2014 20:18:08 +0000 Message-ID: <544EA871.6010507@alum.mit.edu> Date: Mon, 27 Oct 2014 16:17:53 -0400 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: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> In-Reply-To: <544A5742.6050606@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414441088; bh=1xD9aJeHGHAYzaZuO0MaVTf+EPJzJ3HMoZ0DmMGqvgs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=A6Wk6TdE4pEToRgkJz4OdYWH+yN5PMlLQ/l2UIRGVZ3DHdQIsO86AR8zeN7KVqxDb TsFWaRQVGgNKEk11s/KsCiK3pjjmdjEgMQ92I/RYi+eo5MCsQ5CmFJ5OPSQSW3Zmhx k+aqfJqVlY+r1nTAiygPqejxeeT4vtK9Y8TjXtP6ylOrM6JOVwyLl3n39R3ae2DN0M /zwhn9qhLML4ApCnrjV1iuVhj2P9hMEp99zfiTnmZE/CbGiZNhLz3//+6OF+OTMKlT CsalHOsz8Pmlsf0Z6hu/WN9oFAEgmpdjgalqqBhx5j1uodM4N/TrwPb66BhiXJBLr/ QpSfxskDp0mxA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/tWxiwd2b8ORovM-NCS5bwhfzNyA Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:18:17 -0000 I have tried to go through the key changes in the protocol document. Here are the things I noted: The new definition of Advertisement now has a choice of the full adv, or a partial adv. The partial adv starts out directly with add/remove/... I see nothing that explicitly indicates the body that is being modified. Looking at the example, the xpath expression references something like "/advertisement/people", but that could apply to *any* version of the advertisement. I guess the intent is that it reference the "latest" one. But it seems like it would be better to have some identifier that makes clear what is to be modified. For instance, a reference to the sequence number of the advertisement being updated. Why has READV been *removed*? Has something changed so that we don't need it? (I was advocating for renaming it, not removing it.) * Section 4.7: Regarding response code numbering: is the goal to follow SIP or HTTP numbering philosophies? Why are some errors given 3xx codes and others 4xx codes? * Section 6: I have a number of comments on this section and subsections. I'll try to be as specific as I can, but it is hard to discuss potential changes, because everything is interconnected. It would be best if we could have an interactive whiteboard session on this. But I doubt that is in the cards. ... If the CP receives a further OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay in the ACTIVE state. Is this really the best thing to do in this case? Ignoring messages, without even responding, can't come to any good end. I would think that either an error response should be sent to the message, or else the clue session should be terminated. One way to handle this would be to view this as a outer state machine that does the sending/receiving of messages and demuxing them among OPTIONS, MP, and MC state machines. So OPTIONS messages and their responses always go to the OPTIONS state machine, and other messages to their respective state machines. (Messages that are not identifiable as requests or responses destined for any of the sub-state-machines would result is an error that closes the channel.) Initially, the OPTIONS state machine processes OPTIONS messages, while the MP and MC machines consider messages to them errors. After options processing is completed, OPTIONS messages still go to the OPTIONS state machine, but it treats them as errors, sending a suitable error response. Initially the MP and MC state machines treat messages to them as errors. After the options processing is completed, one or both of them enter a state where they process their corresponding messages. * Section 6.1: A general observation: I think it is unclear how the timing of the arrival of messages affects this state machine. It seems unnecessarily complex to deal with a message arriving at any time, yet it seems impossible to avoid that possibility. The best solution I can think of is that there should be a message queue associated with the state machine. When the outer state machine identifies a message that should be processed by this state machine then that message can enter the queue. Then this state machine can process messages from that queue at convenient times. Those times correspond to the "wait for X" states, and the ESTABLISHED state. When in those states, you are really waiting for a message, and then must branch on what sort of message it is. What does "retry expired"/"retry not expired" mean, and how does it relate to "timeout". (Not just here - also in subsequent sections.) I have the impression from past discussions that you intend that there be some time limit or limits to be applied to the receipt of certain expected messages, and also that there be some limited number of retries sending messages when an expected reply has not been received. But I don't find even that much detail in the text, and more than that is needed to make this be a sufficient specification. (There is a *little* bit about retry threshold in 6.2.) Without more detail I can't even guess whether that will work adequately. Next, consider ... CONF+ACK messages referring to out-of-date ADVs should be ignored, i.e., they do not trigger any state transition. Again, ignoring messages seems like a very bad idea. It leads to hangs. I think there must be a response to this, indicating that it has failed. And perhaps also send a new ADV and hope the consumer gets things straightened out after that. * Section 6.2: (Some of the general issues I raised above for 6.1 apply here too.) An MC in the WAIT FOR ADV state is waiting for an ADV coming from the MP. If the ADV arrives ("ADV received"), the MC reaches the PROCESSING ADV state. Otherwise, the MC is stuck in the WAIT FOR ADV state. Suppose what arrives is some message other than an ADV. (I guess the only thing that could be here is a CONF response.) If something odd like that happens then I think it must not be just ignored. But you can't send a response to a response. We may need another message to report bad things. And/or maybe the channel should be torn down. ... If the NACK retry expires ("retry expired"), the MC moves to the MC TERMINATED state. This is a pretty serious state. I think CLUE is still enabled, but the MC is terminated. In that state, what happens to incoming messages? (ADVs) If they aren't responded to then bad things will happen. I think two things are needed: (1) a NAK must still be sent, with indication that this is a fatal error for the MC; (2) in the TERMINATED state messages must still be accepted, with error responses to requests. Ideally, if the MC goes to the TERMINATED state then we want the MP at the other end to also go to that state. When the SDP information arrives, from the ADV RECEIVED or the ADV ACKED state the MC switches to the READY TO CONF state. When the CONF request is ready, the MC sends it and moves to the TRYING state. If the ADV has not yet been sent, the MC can piggyback the ACK message inside the CONF request. ... When the MC is in the SDP O/A state, the telepresence session configuration has been set up at the CLUE application level according to the MC's preferences. Both the MP and the MC have agreed on (and are aware of) the media streams to be exchanged within the call. In this state, the MC waits for the SDP offer coming from the MP. As soon as it arrives, the MC replies with an SDP answer. I wonder if the first of these paragraphs is in the wrong place, or is simply old info no longer intended to be here. For instance, I see no ADV RECEIVED or ADV ACKED states. And it seems in an odd place in the flow of text. In any case, waiting for SDP may present similar issues to waiting for a message. (SDP arrival is far too unsynchronized from the state machine to depend on it arriving exactly when you want it.) So it may be that the state machine needs a queue for this that can be queried from the state that cares. ISTM more consideration is needed of the impact of SDP changes on this state machine. Regarding initiation of an O/A - it certainly can be the case that a new O/A is not needed. I see no provision for that possibility. Perhaps O/A should be handled with a separate state machine - loosely coupled (by events) to both MC and MP machines. (So that a newly accepted CONF triggers an event to the O/A state machine, causing it to analyze the most recent configuration of both MC and MP, and decide if a new offer should be sent.) Considering that both ends are likely to have both an MC and an MP, it seems like it might be tricky to decide who should send a new offer. * Section 11.4: DNS Registrations Why do we need any DNS registrations??? We want a feature tag and an SDP grouping tag, but the signaling draft deals with those. * I didn't yet review the examples. Thanks, Paul On 10/24/14 9:42 AM, Roberta Presta wrote: > Dear all, > we have just uploaded the new version of the protocol document to be > discussed in the next call. > In the following the diff with version 01. > Best regards, > > Roberta > > o The diff mechanism for the ADV message has been introduced. > > o READV and READV RESPONSE message have been both removed. > > o The state machines have been deeply reviewed and changed. > > o References: references have been updated and splitted into > Informative references and Normative references as in framework > v17. > > o Schema: changed in , > in > > o Terminology: many definitions added. Response codes updated. > > > > > > Il 24/10/2014 15:10, internet-drafts@ietf.org ha scritto: >> 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 >> Authors : Roberta Presta >> Simon Pietro Romano >> Filename : draft-ietf-clue-protocol-02.txt >> Pages : 59 >> Date : 2014-10-24 >> >> Abstract: >> The CLUE protocol is an application protocol conceived for the >> description and negotiation of a CLUE telepresence session. The >> design of the CLUE protocol takes into account the requirements and >> the framework defined, respectively, in [I-D.ietf-clue-framework] and >> [I-D.ietf-clue-telepresence-requirements]. The companion document >> [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well >> as on the SIP/SDP session establishment phase. CLUE messages flow >> upon the CLUE data channel, based on reliable and ordered SCTP over >> DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message >> details, together with the behavior of CLUE Participants acting as >> Media Providers and/or Media Consumers, are herein discussed. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-clue-protocol-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Oct 27 13:20:08 2014 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 7C08C1A1A4D; Mon, 27 Oct 2014 13:19:50 -0700 (PDT) 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 kdtQjUQMFxc7; Mon, 27 Oct 2014 13:19:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 149611A1A54; Mon, 27 Oct 2014 13:19:49 -0700 (PDT) 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.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027201949.2326.26942.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:19:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LHLwqFJDPFio7Gs8-vpRffcJnyE Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-04.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: Mon, 27 Oct 2014 20:19:50 -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 Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-04.txt Pages : 34 Date : 2014-10-27 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-signaling-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-04 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 Mon Oct 27 17:32:27 2014 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 2C36F1A6FDE for ; Mon, 27 Oct 2014 17:32:26 -0700 (PDT) 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 qx_U4ocY6w95 for ; Mon, 27 Oct 2014 17:32:23 -0700 (PDT) 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 518FD1A7021 for ; Mon, 27 Oct 2014 17:32:23 -0700 (PDT) Received: from ppp118-209-53-166.lns20.mel4.internode.on.net ([118.209.53.166]:52708 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xiugz-0001oA-Dj for clue@ietf.org; Tue, 28 Oct 2014 11:31:22 +1100 Message-ID: <544EE40B.2000308@nteczone.com> Date: Tue, 28 Oct 2014 11:32:11 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/m5Ro2bevaB3-K2Yu3lN4mPp366Y Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 28 Oct 2014 00:32:26 -0000 Like Christer, I also think the mechanism would be useful. Actually I think its essential when it comes to endpoints (especially gateways) supporting multiple protocols in a data channel. So I hope that MMUSIC does accept the draft. If it does become a general mechanism I think we have to consider it in our CLUE work. Christian On 28/10/2014 6:05 AM, Mary Barnes wrote: > When we discussed this at IETF-90, we said that we would consider it > if the updated document was submitted no later than September 1st (per > the minutes). Of course, that date wasn't met. My suggestion is that > if there is consensus to adopt this as an MMUSIC WG deliverable, we > could add a reference. BUT, I would still be concerned about delays in > that work that would result in CLUE documents sitting in the RFC > editor's queue waiting for that document. > > As an individual, considering the overall pace of the work on that > document thus far, I would be quite worried about adding that as a > dependency. > > Regards, > Mary. > > On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg > > wrote: > > FYI, > > Keith has submitted a new version of the SDP-data-channel-neg draft. > > Personally I think the mechanism would be useful, but I think it > would be good to have a "CLUE opinion" also. Currently we only > have an editor's note saying that we may consider the mechanism > depending on how it progresses. But, as we know, nothing > progresses by itself in IETF, so the question is whether we shall > say "CLUE has an interest in this mechanism, and would like it to > move forward". > > Regards, > > Christer > > > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org > ] On Behalf Of DRAGE, Keith (Keith) > Sent: 27 October 2014 16:39 > To: mmusic@ietf.org > Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and > draft-ejzak-mmusic-msrp-usage-data-channel > > Based on the discussion on list over the last few days, I have > submitted revised versions of the two SDP negotiation over data > channel drafts as follows: > > A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt > has been successfully submitted by Keith Drage and posted to the > IETF repository. > > Name: draft-ejzak-mmusic-data-channel-sdpneg > Revision: 02 > Title: SDP-based "SCTP over DTLS" data channel negotiation > Document date: 2014-10-27 > Group: Individual Submission > Pages: 22 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02 > > Abstract: > The Real-Time Communication in WEB-browsers (RTCWeb) working > group is > charged to provide protocols to support direct interactive rich > communications using audio, video, and data between two peers' web- > browsers. For the support of data communication, the RTCWeb > working > group has in particular defined the concept of bi-directional data > channels over SCTP, where each data channel might be used to > transport other protocols, called sub-protocols. Data channel setup > can be done using either the internal in-band band (also > referred to > as 'internal' for the rest of the document) WebRTC Data Channel > Establishment Protocol or some external out-of-band simply referred > to as 'external negotiation' in the rest of the document . This > document specifies how the SDP offer/answer exchange can be used to > achieve such an external negotiation. Even though data > channels are > designed for RTCWeb use initially they may be used by other > protocols > like, but not limited to, the CLUE protocol. This document is > intended to be used wherever data channels are used. > > > A new version of I-D, > draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > has been successfully submitted by Keith Drage and posted to the > IETF repository. > > Name: draft-ejzak-mmusic-msrp-usage-data-channel > Revision: 01 > Title: MSRP over SCTP/DTLS data channels > Document date: 2014-10-27 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/ > Htmlized: > http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01 > > Abstract: > This document specifies how the Message Session Relay Protocol > (MSRP) > can be instantiated as a data channel sub-protocol, using the > the SDP > offer/answer exchange-based external negotiation defined in > [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network configurations > are documented: a WebRTC end-to-end configuration (connecting two > MSRP over data channel endpoints), and a gateway configuration > (connecting an MSRP over data channel endpoint with an MSRP > over TCP > endpoint). > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > 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 Oct 27 17:56:04 2014 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 5E4BB1A1B9C for ; Mon, 27 Oct 2014 17:55:57 -0700 (PDT) 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 OpQcuB5Y_D8v for ; Mon, 27 Oct 2014 17:55:54 -0700 (PDT) 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 BD6E61A870B for ; Mon, 27 Oct 2014 17:55:53 -0700 (PDT) Received: from ppp118-209-53-166.lns20.mel4.internode.on.net ([118.209.53.166]:52889 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xiv3l-0004sl-UM for clue@ietf.org; Tue, 28 Oct 2014 11:54:54 +1100 Message-ID: <544EE990.5060607@nteczone.com> Date: Tue, 28 Oct 2014 11:55:44 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <034b01cfed72$18953500$49bf9f00$@gmail.com> <5449B24B.6020200@nteczone.com> <05f501cfef84$b241ec20$16c5c460$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F5C5AB78A83@CRPMBOXPRD08.polycom.com> <544A84EB.8060203@alum.mit.edu> <066401cff063$773033f0$65909bd0$@gmail.com> <544D68BB.9060701@alum.mit.edu> <06c301cff168$35ac97b0$a105c710$@gmail.com> <544D8592.3010408@alum.mit.edu> <06f701cff1cf$a57c1310$f0743930$@gmail.com> In-Reply-To: <06f701cff1cf$a57c1310$f0743930$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/CWjbEpnfVMQELzhkzkc3V75b6BA Subject: Re: [clue] CLUE and Simulcast - ticket #47 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, 28 Oct 2014 00:55:58 -0000 Hello Roni, As I mentioned in my original reply I think the RTP based simulcast method is probably the cleanest approach. There would be nothing stopping a CLUE endpoint implementing it when it becomes available (like many other RTP features). Using CLUE for simulcast I think is possible for most scenarios. The more complicated the scenarios the more MCs/encodings an endpoint will need to describe the situation. Please see my response below. Regards, Christian On 27/10/2014 9:20 PM, Roni Even wrote: > Hi Paul, > > If we want to be able to differentiate between simulcast and switched > capture, for example if we have a three camera system that can send three > MCs each with two encodings (simulcast) and a switched capture (loudest > speaker or two loudest speakers out of three) using the same simulcast > option for the each MC currently sent. In this case we can have an MC with > two encodings and an MCC with the three MCs. This will require us to clarify > that having multiple individual encodings in MC is simulcast and not > switched and in MCC it is switched and not simulcast. [CNG] I don't understand exactly what the issue is here? Could you use some pseudo syntax to explain what you're wanting to advertise? You say in the first sentence the switched capture uses simulcast but then in the last sentence you say the MCC is switched and not simulcast. I would think that an MCC can still be switched and simulcast, i.e. the endpoint simulcasts whatever source is switched into the media stream. If you want a pure switched MCC just set maxCaptureEncodings to 1 against the MCC. If you want a simultcast MCC just set maxCaptureEncodings to >=2 against the MCC. > > Now what may complicate the advertisement is if the individual MCs can > simulcast two encodings while the MCC (switched) is only with one encoding, > this may require different MCs for MCC or individual MCs case. [CNG] Probably. > > As for the data model draft, the example > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-26 > may be confusing. > It has for VC0, VC1 and VC2 2 > while the EG0 has only three encID so if it was meant to support simulcast > it will require six encID for Scene View SE1. [CNG] Yes I think you're right. Its worth clarifying this. We could add some text in the introduction of the example saying simulcast is used. > > Roni > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: 27 October, 2014 1:37 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >> >> On 10/26/14 6:00 PM, Roni Even wrote: >>> Paul, >>> How does the consumer know that he can configure an MC with two >>> encodings, and which of the encodings are allowed to co-exist? >> Look at the data model definition of a capture. It has a field >> . That says how many simultaneous encodings of the >> capture are allowed. >> >> So, if the encoding group for the capture includes more than one encoding, > and >> maxCaptureEncodings is greater than one, then the consumer can configure >> simulcast. >> >> Thanks, >> Paul >> >> >>> Roni >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: 26 October, 2014 11:34 PM >>>> To: Roni Even; clue@ietf.org >>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>> >>>> On 10/25/14 10:53 AM, Roni Even wrote: >>>>> Hi Paul, >>>>> Inline >>>>> Roni >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: 24 October, 2014 7:57 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>> >>>>>> I agree with Mark here. >>>>>> >>>>>> Consider a plausible use case in clue: >>>>>> >>>>>> The advertiser has a number of captures, and has a number of > encoders. >>>>>> It can create an encoding group with all the encoders in it - some >>>>>> do >>>>> hi-res >>>>>> video, some do small videos. It puts all of those in an encoding >>>>>> group and associates all the captures with that group. >>>>>> >>>>>> A "normal" consumer might configure a few of the captures with the >>>>>> hi-res encodings, and some of the other captures with the small >>>>>> encodings. There would be no simulcast in this case. >>>>>> >>>>>> Some other consumer (e.g., an MCC) may decide it wants one of the >>>>>> captures in both big and small versions of one of the MCCs. It can >>>>>> simply do an appropriate configuration and get that. Now we have >>>>>> *simulcast*! The advertiser didn't have to do anything special - >>>>>> didn't have to think about simulcast at all. >>>>> [Roni Even] How does the consumer know that these MCs are different >>>>> potential encodings of the same source. >>>>> Marks, suggested different encoding group for each encoding so he >>>>> can advertise MC1 with ENC1 and ENC2, in this case the encoding >>>>> groups will represent different encoding parameters but will need to >>>>> be defined accordingly, for example one encoding group that has CIF >>>>> resolutions and the other with only HD resolutions >>>> This works when the advertisement assigns the capture to an encoding >>>> group containing multiple encodings. When the consumer configures the >>>> same encoding twice, using different encodings from the encoding >>>> group, then he knows - by definition - they are simulcasts. >>>> >>>> Thanks, >>>> Paul >>>> >>>>>> If an advertiser *wants* to use >>>>>> draft-westerlund-avtcore-rtp-simulcast >>>>>> then I see no reason to prevent that. But I would hate to force >>>>>> that >>>>> (especially >>>>>> since it isn't approved yet). >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> On 10/24/14 9:47 AM, Duckworth, Mark wrote: >>>>>>> Hello Roni and Christian, >>>>>>> >>>>>>> I believe CLUE already supports simulcast today, basically as >>>>>>> Christian >>>>>> describes. >>>>>>> More below. >>>>>>> >>>>>>> (trying to use both the "correct indentation with > > symbols", >>>>>>> and also marking comments with my name :-) >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even >>>>>>>> Sent: Friday, October 24, 2014 8:19 AM >>>>>>>> To: 'Christian Groves'; clue@ietf.org >>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>> >>>>>>>> Hi Christian, >>>>>>>> Inline >>>>>>>> Roni >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian >>>>>>>>> Groves >>>>>>>>> Sent: 24 October, 2014 4:59 AM >>>>>>>>> To: clue@ietf.org >>>>>>>>> Subject: Re: [clue] CLUE and Simulcast - ticket #47 >>>>>>>>> >>>>>>>>> Hello Roni, >>>>>>>>> >>>>>>>>> Supporting draft-westerlund-avtcore-rtp-simulcast-04 >>>>>>>>> >>>>>>>> st >>>>>>>>> -0 >>>>>>>>> 4> seems like the most straight forward approach as it keeps >>>>>>>>> 4> things >>>>>>>>> at the encoding level, which is really where simulcast belongs. >>>>>>> [Duckworth, Mark] Does CLUE really need to say anything about this? >>>>>>> Isn't this separate from CLUE, and can be used with CLUE without >>>>>>> any further specification in CLUE documents? >>>>>>> >>>>>>>>> For a CLUE based solution I don't think we need to revert to MCCs. >>>>>>>>> The purpose of simulcast is to provide different encoding >>>>>>>>> options for a particular media stream. A media provider can >>>>>>>>> Advertise a MC >>>>> with >>>>>> multiple encoding groups. >>>>>>>>> A media consumer if it wants to receive multiple encodings for >>>>>>>>> the same MC can simply choose multiple capture encodings e.g. >>>>>>>>> MC1/Encoding1 >>>>>>>>> MC1/Encoding2 etc. >>>>>>> [Duckworth, Mark] Yes, a media provider can support multiple >>>>>>> encodings for the same MC, and a consumer can choose to configure >>>>>>> multiple encodings for the same MC. You don't even need multiple >>>>>>> encoding groups to do this, you can do it with just one group that >>>>>>> contains >>>>> multiple >>>>>> encodings. >>>>>>>> [Roni Even] How does the media consumer know that these are >>>>>>>> alternatives of a simulcast stream and know how many can be used >>>>>>>> at the >>>>>> same time. >>>>>>> [Duckworth, Mark] By the MC attribute "max capture encodings". >>>>>>> Any encodings in the MC's encoding groups can be configured for a >>>>>>> particular MC, simultaneously, up to the value of "max capture >>>>> encodings". >>>>>>>> You also lose here the option of the total BW that is an encoding >>>>>>>> group >>>>>> attribute. >>>>>>> [Duckworth, Mark] You can still use that by advertising an MC with >>>>>>> a single encoding group, with multiple encodings in the group. >>>>>>> >>>>>>>> All these means that we need some changes to CLUE and we can look >>>>>>>> at what will make the best solution using MCs or MMCs. >>>>>>> [Duckworth, Mark] I believe we don't need any changes in CLUE, all >>>>>>> this is already supported. >>>>>>> >>>>>>>> Still the question is if we say that we will use the SDP based >>>>>>>> solution even though it is not a WG draft, having it as a >>>>>>>> normative reference will delay the publication of the CLUE draft >>>>>>>> >>>>>>>>> Regards, Christian >>>>>>>>> >>>>>>>>> On 22/10/2014 8:00 AM, Roni Even wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> During our weekly design team meeting we discussed simulcast >>>>>>>>>> support in CLUE. >>>>>>>>>> >>>>>>>>>> Here is my take on the options, my description may not be >>>>>>>>>> accurate and the purpose here is to continue the discussion >>>>>>>>>> allowing us to have a better view of the options. >>>>>>>>>> >>>>>>>>>> Looking at the state of simulcast support in other WGs, there >>>>>>>>>> is an individual draft >>>>>>>>>> http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulca >>>>>>>>>> st >>>>>>>>>> -0 >>>>>>>>>> 4 that being discussed. The proposed solution is based on the >>>>>>>>>> unified plan where all encoded streams composing alternatives >>>>>>>>>> of a simulcast stream are in the same m-line. The alternatives >>>>>>>>>> are described using an SDP media level attribute "a=simulcast". >>>>>>>>>> This attribute is not defined for SDP session level. >>>>>>>>>> >>>>>>>>>> The first question we had is if we should base CLUE simulcast >>>>>>>>>> support on this individual draft based on CLUE timeline or try >>>>>>>>>> to define a different multicast solution at the CLUE protocol > level. >>>>>>>>>> If we base our solution on the avtcore-rtp-simulcast-04 >>>>>>>>>> document the advertisement will include an individual encoding >>>>>>>>>> that will relate to optional multiple simulcast encoding and >>>>>>>>>> the configure will select such encoding. The actual number of >>>>>>>>>> different stream that will compose the simulcast stream will be >>>>>>>>>> negotiated using Offer/Answer as described in the above >>>>>>>>>> document. The risk here is that this is an individual draft and >>>>>>>>>> we may need to review the CLUE support if it changes. The >>>>>>>>>> advantage is that we will have simulcast the same for CLUE and > non- >> CLUE systems. >>>>>>>>>> The other option for simulcast support in the CLUE protocol can >>>>>>>>>> be based on having separate Media Capture for each of the >>>>>>>>>> different simulcast encoding and use MCC to compose the >>>>>>>>>> simulcast >>>> alternatives. >>>>>>>>>> We will need some way to escribe that this MCC is for simulcast >>>>>>>>>> description and to provide the actual allowed individual >>>>>>>>>> encodes combinations for the Configuration by the consumer. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Roni >>>>>>> _______________________________________________ >>>>>>> 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 Oct 27 17:58:40 2014 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 E72851A87C1 for ; Mon, 27 Oct 2014 17:58:37 -0700 (PDT) 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 eb0ryLVmKwI5 for ; Mon, 27 Oct 2014 17:58:32 -0700 (PDT) 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 9760A1A870E for ; Mon, 27 Oct 2014 17:58:32 -0700 (PDT) Received: from ppp118-209-53-166.lns20.mel4.internode.on.net ([118.209.53.166]:53028 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xiv6K-0005d0-Si for clue@ietf.org; Tue, 28 Oct 2014 11:57:33 +1100 Message-ID: <544EEA2F.5060608@nteczone.com> Date: Tue, 28 Oct 2014 11:58:23 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CCF6F@ESESSMB209.ericsson.se> <544E558C.8070209@alum.mit.edu> In-Reply-To: <544E558C.8070209@alum.mit.edu> 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/YHRTxnvOSgtSiqDpaF1AN25wvBU Subject: Re: [clue] FW: Meaning of SHOULD support/use interleaving 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, 28 Oct 2014 00:58:38 -0000 It seems that RTCWEB is leaning to that this is now "MUST"? Christian On 28/10/2014 1:24 AM, Paul Kyzivat wrote: > On 10/27/14 9:23 AM, Christer Holmberg wrote: >> FYI, >> >> As agreed at the design team meeting a few weeks ago, I have sent the >> following e-mail to the RTCWEB list. > > Thanks Christer! > >> Regards, >> >> Christer >> >> *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Christer >> Holmberg >> *Sent:* 27. lokakuuta 2014 15:13 >> *To:* rtcweb@ietf.org >> *Subject:* [rtcweb] Meaning of SHOULD support/use interleaving >> >> Hi, >> >> Within the CLUE WG, we had a discussion regarding the following >> statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >> >> The support for message interleaving as defined in >> >> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used. >> >> First, it is a little unclear what the support SHOULD be used means. >> >> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD >> use interleaving, even if the characteristics of the protocol wouldnt >> require it? >> >> 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 > From nobody Tue Oct 28 01:09:49 2014 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 CD1C61A0385 for ; Tue, 28 Oct 2014 01:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekTQb46kuwDh for ; Tue, 28 Oct 2014 01:09:19 -0700 (PDT) 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 8903F1A1A77 for ; Tue, 28 Oct 2014 01:08:12 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-13-544f4ee3c989 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.7A.04387.3EE4F445; Tue, 28 Oct 2014 09:08:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 09:08:03 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] FW: Meaning of SHOULD support/use interleaving Thread-Index: Ac/x55WTmtr0wn1FRpKkoOi9WMJX3wAAWmcQAAATLQAAFiYKgAARE1ag Date: Tue, 28 Oct 2014 08:08:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4CF376@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4CCEEF@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4CCF6F@ESESSMB209.ericsson.se> <544E558C.8070209@alum.mit.edu> <544EEA2F.5060608@nteczone.com> In-Reply-To: <544EEA2F.5060608@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje4TP/8Qg3czuC2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJWx/tZztoLFvBVzHoY3MN7m6mLk5JAQMJE4 vrCPGcIWk7hwbz1bFyMXh5DAEUaJ1jMHWCCcJYwSVw/NBMpwcLAJWEh0/9MGaRARCJfo2HaF ESQsLOAksewCO0TYWWLF49NQtpvEjJtLWEBsFgFVieaFqxlBbF4BX4m+c8eZIcZfZpSYvGQz K0iCU0BHYvPVV2ANjEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nIc6WlTi5eN/rCA3SAgoSizv l4Mo15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG0eLU4uLc dCMjvdSizOTi4vw8vbzUkk2MwBg5uOW31Q7Gg88dDzEKcDAq8fBuYPMPEWJNLCuuzD3EKM3B oiTOu/DcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjOYGl5QZG7+1ui7KrxLd9eeE4hrZ 6P3/r9mtbzi58Mta/ssCmw8pu3rts/ri/Gzfxnvi57Wr5yhaPPkkuHX6hOvi3HN3K7m97C27 qZLYLS3h+sTV6cjiHdnPbl/Nyr+w9yNPFFvCdLaGhhC11dnnHl89LF0cH2Fan/GM/emfVbNE 9yw/u2jFXQUlluKMREMt5qLiRAAbt+oCcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3Mz1wOq-7TRxBeIV5ZGjHOYng_k Subject: Re: [clue] FW: Meaning of SHOULD support/use interleaving 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, 28 Oct 2014 08:09:22 -0000 Hi, >It seems that RTCWEB is leaning to that this is now "MUST"? Yes. I have not manage to get a reply whether it's really needed for CLUE, thoug= h :) Regards, Christer On 28/10/2014 1:24 AM, Paul Kyzivat wrote: > On 10/27/14 9:23 AM, Christer Holmberg wrote: >> FYI, >> >> As agreed at the design team meeting a few weeks ago, I have sent the=20 >> following e-mail to the RTCWEB list. > > Thanks Christer! > >> Regards, >> >> Christer >> >> *From:*rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of=20 >> *Christer Holmberg >> *Sent:* 27. lokakuuta 2014 15:13 >> *To:* rtcweb@ietf.org >> *Subject:* [rtcweb] Meaning of SHOULD support/use interleaving >> >> Hi, >> >> Within the CLUE WG, we had a discussion regarding the following=20 >> statement in section 6.1 of draft-ietf-rtcweb-data-channel-12.txt: >> >> "The support for message interleaving as defined in >> >> [I-D.ietf-tsvwg-sctp-ndata] SHOULD be used." >> >> First, it is a little unclear what "the support SHOULD be used" means. >> >> Second, does it mean that any data channel protocol (e.g CLUE) SHOULD=20 >> use interleaving, even if the characteristics of the protocol=20 >> wouldn't require it? >> >> 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 From nobody Tue Oct 28 05:46:52 2014 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 492BB1A88FA for ; Tue, 28 Oct 2014 05:46:12 -0700 (PDT) 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 A-W3dGDmjMd4 for ; Tue, 28 Oct 2014 05:46:09 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840921A8882 for ; Tue, 28 Oct 2014 05:40:21 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id b6so496200lbj.6 for ; Tue, 28 Oct 2014 05:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EtoDsKNH8nqAdwC/QzpMs3lpSGuyI9QA5JfDki324oQ=; b=vHujZ4HKbgcJP3piOyOGND4c+3XTwE9AbFJGe48a+hTPtO/lUQpDXmPNTqokQJULMx eWGgc+jRnitAyz0gQK/7f2ptOAvmppr/UhVF/jpk2Vd8Ar8v1OvtAX3e8WCtB9WFoJ5d I/khVZ+0Xme0BO43jNMm4RwbvAhG0hKcxvG9RMRA+WULXB81lorz6EGdUQFoe2FEJFfV WoVlWQkM/a3+q9+LyG5Sf0U5kKSn5qoJRMjNpoPqbO1e6zfRvpXhbbGDec11wYBw1ro1 DUM0O8zdNhZewSvUKauNyLv6ag8Xo4gVAwdYnUqJ5jCgCYb++Qkicq+pL9qb3LczEro9 EeeQ== MIME-Version: 1.0 X-Received: by 10.152.5.201 with SMTP id u9mr3786361lau.24.1414500019389; Tue, 28 Oct 2014 05:40:19 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 05:40:19 -0700 (PDT) In-Reply-To: <544EE40B.2000308@nteczone.com> References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> <544EE40B.2000308@nteczone.com> Date: Tue, 28 Oct 2014 07:40:19 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e0141a24230c90c05067af3a6 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5IA-FHkMkeqSB6O4r3trmKW-Af8 Cc: CLUE Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 28 Oct 2014 12:46:12 -0000 --089e0141a24230c90c05067af3a6 Content-Type: text/plain; charset=UTF-8 Okay. So, if folks really want this for CLUE, then we MUST make sure to support the work on the MMUSIC WG mailing list. As I said, my primary concern is timing. If the current author doesn't have the cycles (or needs help), would anyone here be willing to step in as a co-author (if the doc is agreed as a WG document) to ensure the work actually gets done? Thanks, Mary On Mon, Oct 27, 2014 at 7:32 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Like Christer, I also think the mechanism would be useful. Actually I > think its essential when it comes to endpoints (especially gateways) > supporting multiple protocols in a data channel. So I hope that MMUSIC does > accept the draft. If it does become a general mechanism I think we have to > consider it in our CLUE work. > > Christian > > On 28/10/2014 6:05 AM, Mary Barnes wrote: > >> When we discussed this at IETF-90, we said that we would consider it if >> the updated document was submitted no later than September 1st (per the >> minutes). Of course, that date wasn't met. My suggestion is that if there >> is consensus to adopt this as an MMUSIC WG deliverable, we could add a >> reference. BUT, I would still be concerned about delays in that work that >> would result in CLUE documents sitting in the RFC editor's queue waiting >> for that document. >> >> As an individual, considering the overall pace of the work on that >> document thus far, I would be quite worried about adding that as a >> dependency. >> >> Regards, >> Mary. >> >> On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg < >> christer.holmberg@ericsson.com > >> wrote: >> >> FYI, >> >> Keith has submitted a new version of the SDP-data-channel-neg draft. >> >> Personally I think the mechanism would be useful, but I think it >> would be good to have a "CLUE opinion" also. Currently we only >> have an editor's note saying that we may consider the mechanism >> depending on how it progresses. But, as we know, nothing >> progresses by itself in IETF, so the question is whether we shall >> say "CLUE has an interest in this mechanism, and would like it to >> move forward". >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: mmusic [mailto:mmusic-bounces@ietf.org >> ] On Behalf Of DRAGE, Keith (Keith) >> Sent: 27 October 2014 16:39 >> To: mmusic@ietf.org >> Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and >> draft-ejzak-mmusic-msrp-usage-data-channel >> >> Based on the discussion on list over the last few days, I have >> submitted revised versions of the two SDP negotiation over data >> channel drafts as follows: >> >> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt >> has been successfully submitted by Keith Drage and posted to the >> IETF repository. >> >> Name: draft-ejzak-mmusic-data-channel-sdpneg >> Revision: 02 >> Title: SDP-based "SCTP over DTLS" data channel negotiation >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 22 >> URL: >> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic- >> data-channel-sdpneg-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data- >> channel-sdpneg/ >> Htmlized: >> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data- >> channel-sdpneg-02 >> >> Abstract: >> The Real-Time Communication in WEB-browsers (RTCWeb) working >> group is >> charged to provide protocols to support direct interactive rich >> communications using audio, video, and data between two peers' web- >> browsers. For the support of data communication, the RTCWeb >> working >> group has in particular defined the concept of bi-directional data >> channels over SCTP, where each data channel might be used to >> transport other protocols, called sub-protocols. Data channel setup >> can be done using either the internal in-band band (also >> referred to >> as 'internal' for the rest of the document) WebRTC Data Channel >> Establishment Protocol or some external out-of-band simply referred >> to as 'external negotiation' in the rest of the document . This >> document specifies how the SDP offer/answer exchange can be used to >> achieve such an external negotiation. Even though data >> channels are >> designed for RTCWeb use initially they may be used by other >> protocols >> like, but not limited to, the CLUE protocol. This document is >> intended to be used wherever data channels are used. >> >> >> A new version of I-D, >> draft-ejzak-mmusic-msrp-usage-data-channel-01.txt >> has been successfully submitted by Keith Drage and posted to the >> IETF repository. >> >> Name: draft-ejzak-mmusic-msrp-usage-data-channel >> Revision: 01 >> Title: MSRP over SCTP/DTLS data channels >> Document date: 2014-10-27 >> Group: Individual Submission >> Pages: 11 >> URL: >> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic- >> msrp-usage-data-channel-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp- >> usage-data-channel/ >> Htmlized: >> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage- >> data-channel-01 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp- >> usage-data-channel-01 >> >> Abstract: >> This document specifies how the Message Session Relay Protocol >> (MSRP) >> can be instantiated as a data channel sub-protocol, using the >> the SDP >> offer/answer exchange-based external negotiation defined in >> [I-D.ejzak-mmusic-data-channel-sdpneg]. Two network >> configurations >> are documented: a WebRTC end-to-end configuration (connecting two >> MSRP over data channel endpoints), and a gateway configuration >> (connecting an MSRP over data channel endpoint with an MSRP >> over TCP >> endpoint). >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> 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 > --089e0141a24230c90c05067af3a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay. So, if folks really want this for CLUE, then we MUST= make sure to support the work on the MMUSIC WG mailing list. =C2=A0 As I s= aid, my primary concern is timing. If the current author doesn't have t= he cycles (or needs help), would anyone here be willing to step in as a co-= author (if the doc is agreed as a WG document) to ensure the work actually = gets done?

Thanks,
Mary

On Mon, Oct 27, 2014 at 7:3= 2 PM, Christian Groves <Christian.Groves@nteczone.com><= /span> wrote:
Like Christer, I also think= the mechanism would be useful. Actually I think its essential when it come= s to endpoints (especially gateways) supporting multiple protocols in a dat= a channel. So I hope that MMUSIC does accept the draft. If it does become a= general mechanism I think we have to consider it in our CLUE work.

Christian

On 28/10/2014 6:05 AM, Mary Barnes wrote:
When we discussed this at IETF-90, we said that we would consider it if the= updated document was submitted no later than September 1st (per the minute= s).=C2=A0 Of course, that date wasn't met.=C2=A0 My suggestion is that = if there is consensus to adopt this as an MMUSIC WG deliverable, we could a= dd a reference. BUT, I would still be concerned about delays in that work t= hat would result in CLUE documents sitting in the RFC editor's queue wa= iting for that document.

As an individual, considering the overall pace of the work on that document= thus far, I would be quite worried about adding that as a dependency.

Regards,
Mary.

 On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg <christer.holmberg@ericsson.= com <mailto:christer.holmberg@ericsson.com>> wrote:=

=C2=A0 =C2=A0 FYI,

=C2=A0 =C2=A0 Keith has submitted a new version of the SDP-data-channel-neg= draft.

=C2=A0 =C2=A0 Personally I think the mechanism would be useful, but I think= it
=C2=A0 =C2=A0 would be good to have a "CLUE opinion" also. Curren= tly we only
=C2=A0 =C2=A0 have an editor's note saying that we may consider the mec= hanism
=C2=A0 =C2=A0 depending on how it progresses. But, as we know, nothing
=C2=A0 =C2=A0 progresses by itself in IETF, so the question is whether we s= hall
=C2=A0 =C2=A0 say "CLUE has an interest in this mechanism, and would l= ike it to
=C2=A0 =C2=A0 move forward".

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 Christer


=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: mmusic [mailto:mmusic-bounces@ietf.org
=C2=A0 =C2=A0 <mailto:mmusic-bounces@ietf.org>] On Behalf Of DRAGE, Kei= th (Keith)
=C2=A0 =C2=A0 Sent: 27 October 2014 16:39
=C2=A0 =C2=A0 To: mmus= ic@ietf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpn= eg and
=C2=A0 =C2=A0 draft-ejzak-mmusic-msrp-usage-data-channel

=C2=A0 =C2=A0 Based on the discussion on list over the last few days, I hav= e
=C2=A0 =C2=A0 submitted revised versions of the two SDP negotiation over da= ta
=C2=A0 =C2=A0 channel drafts as follows:

=C2=A0 =C2=A0 A new version of I-D, draft-ejzak-mmusic-data-channel-= sdpneg-02.txt
=C2=A0 =C2=A0 has been successfully submitted by Keith Drage and posted to = the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ejzak-mmu= sic-data-channel-sdpneg
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SDP-based "SCTP= over DTLS" data channel negotiation
=C2=A0 =C2=A0 Document date:=C2=A0 2014-10-27
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submissio= n
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 22
=C2=A0 =C2=A0 URL:
=C2=A0 =C2=A0 http://www.ietf.org/inte= rnet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt=
=C2=A0 =C2=A0 Status:
=C2=A0 =C2=A0 https://datatracker.ietf.org/<= /u>doc/draft-ejzak-mmusic-data-channel-sdpneg/
=C2=A0 =C2=A0 Htmlized:
=C2=A0 =C2=A0 http://tools.ietf.org/html/dra= ft-ejzak-mmusic-data-channel-sdpneg-02
=C2=A0 =C2=A0 Diff:
=C2=A0 =C2=A0 http://www.ietf.org/rfcdiff?<= u>url2=3Ddraft-ejzak-mmusic-data-channel-sdpneg-02

=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0The Real-Time Communication in WEB-browsers (RTC= Web) working
=C2=A0 =C2=A0 group is
=C2=A0 =C2=A0 =C2=A0 =C2=A0charged to provide protocols to support direct i= nteractive rich
=C2=A0 =C2=A0 =C2=A0 =C2=A0communications using audio, video, and data betw= een two peers' web-
=C2=A0 =C2=A0 =C2=A0 =C2=A0browsers.=C2=A0 For the support of data communic= ation, the RTCWeb
=C2=A0 =C2=A0 working
=C2=A0 =C2=A0 =C2=A0 =C2=A0group has in particular defined the concept of b= i-directional data
=C2=A0 =C2=A0 =C2=A0 =C2=A0channels over SCTP, where each data channel migh= t be used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0transport other protocols, called sub-protocols.= Data channel setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0can be done using either the internal in-band ba= nd (also
=C2=A0 =C2=A0 referred to
=C2=A0 =C2=A0 =C2=A0 =C2=A0as 'internal' for the rest of the docume= nt) WebRTC Data Channel
=C2=A0 =C2=A0 =C2=A0 =C2=A0Establishment Protocol or some external out-of-b= and simply referred
=C2=A0 =C2=A0 =C2=A0 =C2=A0to as 'external negotiation' in the rest= of the document . This
=C2=A0 =C2=A0 =C2=A0 =C2=A0document specifies how the SDP offer/answer exch= ange can be used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0achieve such an external negotiation.=C2=A0 Even= though data
=C2=A0 =C2=A0 channels are
=C2=A0 =C2=A0 =C2=A0 =C2=A0designed for RTCWeb use initially they may be us= ed by other
=C2=A0 =C2=A0 protocols
=C2=A0 =C2=A0 =C2=A0 =C2=A0like, but not limited to, the CLUE protocol.=C2= =A0 This document is
=C2=A0 =C2=A0 =C2=A0 =C2=A0intended to be used wherever data channels are u= sed.


=C2=A0 =C2=A0 A new version of I-D,
=C2=A0 =C2=A0 draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
=C2=A0 =C2=A0 has been successfully submitted by Keith Drage and posted to = the
=C2=A0 =C2=A0 IETF repository.

=C2=A0 =C2=A0 Name:=C2=A0 draft-ejzak-mmusic-msrp-usage-data-channel=
=C2=A0 =C2=A0 Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MSRP over SCTP/DTLS = data channels
=C2=A0 =C2=A0 Document date:=C2=A0 2014-10-27
=C2=A0 =C2=A0 Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submissio= n
=C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
=C2=A0 =C2=A0 URL:
=C2=A0 =C2=A0 http://www.ietf.org/= internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01= .txt
=C2=A0 =C2=A0 Status:
=C2=A0 =C2=A0 https://datatracker.ietf.org/= doc/draft-ejzak-mmusic-msrp-usage-data-channel/
=C2=A0 =C2=A0 Htmlized:
=C2=A0 =C2=A0 http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
=C2=A0 =C2=A0 Diff:
=C2=A0 =C2=A0 http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ejzak-mmusic-msrp-usage-data-channel-01
=C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies how the Message Session = Relay Protocol
=C2=A0 =C2=A0 (MSRP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0can be instantiated as a data channel sub-protoc= ol, using the
=C2=A0 =C2=A0 the SDP
=C2=A0 =C2=A0 =C2=A0 =C2=A0offer/answer exchange-based external negotiation= defined in
=C2=A0 =C2=A0 =C2=A0 =C2=A0[I-D.ejzak-mmusic-data-channel-sdpneg].= =C2=A0 Two network configurations
=C2=A0 =C2=A0 =C2=A0 =C2=A0are documented: a WebRTC end-to-end configuratio= n (connecting two
=C2=A0 =C2=A0 =C2=A0 =C2=A0MSRP over data channel endpoints), and a gateway= configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0(connecting an MSRP over data channel endpoint w= ith an MSRP
=C2=A0 =C2=A0 over TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint).
=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 mmusic mailing list
=C2=A0 =C2=A0 mmusic@i= etf.org <mailto:mmusic@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/mmusic

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




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

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

--089e0141a24230c90c05067af3a6-- From nobody Tue Oct 28 05:58:25 2014 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 C6E391A87D6 for ; Tue, 28 Oct 2014 05:57:51 -0700 (PDT) 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 r6aViswwFn61 for ; Tue, 28 Oct 2014 05:57:48 -0700 (PDT) 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 A380E1A8786 for ; Tue, 28 Oct 2014 05:52:29 -0700 (PDT) X-AuditID: c1b4fb30-f79e66d000000ff1-a4-544f918be846 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AD.45.04081.B819F445; Tue, 28 Oct 2014 13:52:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 13:52:27 +0100 From: Christer Holmberg To: Mary Barnes , Christian Groves Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: Ac/x88lK6mpn4HE9TuemRholN7+6tQAHy8mw///7LgCAAFtXgIAAy3CA///s8HA= Date: Tue, 28 Oct 2014 12:52:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D0AEB@ESESSMB209.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> <544EE40B.2000308@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D0AEBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGfG3Rrd7on+IwYpJRhZf3jeyWOw/dZnZ 4vP+/cwOzB47Z91l91iy5CeTx4rzM1kCmKO4bFJSczLLUov07RK4Ml4de8FUcOArY0X/1y0s DYwt7xm7GDk5JARMJFatO8YOYYtJXLi3nq2LkYtDSOAIo8Ty4xvYIZwljBJXT9wEcjg42AQs JLr/aYM0iAgkSNw6sp0JxGYWkJBYdfED2FBhgXyJdT3NLBA1BRK3FzYC1bAD2X4STWogURYB VYm7hx+wgti8Ar4Sczc/ZoTYdI5J4siuJWAjOQUCJTasXQBWxAh02/dTa6BWiUvcejKfCeJm AYkle84zQ9iiEi8f/2MFuVJCQFFieb8cRHm+xNp51xkhdglKnJz5hGUCo+gsJJNmISmbhaRs FtAkZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8v tWQTIzACD275bbCD8eVzx0OMAhyMSjy8BuX+IUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgXF9guStwtiVIvt/Hdv/pe0r+2yPDQIhCpP9S2J9goVT+eNu pOz88t1DPXgp7/W+ykVnJs1M+zTnt2APQ15N676pPB1H31/oVd5Wo/Xykn4KV6flJFejVwvv xfnkdDy89PiS1/mD/+RYbzN+yt7JW8THMCXfMOjx5XPhRldjv71scjny0Vdu2UklluKMREMt 5qLiRABnJoe2oQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/B5PWiPH602irKWQKZjUn4oIAgIY Cc: CLUE Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 28 Oct 2014 12:57:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D0AEBESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd291bGQgYmUgd2lsbGluZyB0byBoZWxwIHRoZSBhdXRob3IocyksIGlmIHRoZXkg bmVlZCBoZWxwIDopDQoNCk9mIGNvdXJzZSwgU0RQIGF0dHJpYnV0ZXMgKHdoaWNoIHRoZSBkcmFm dCB0ZWNobmljYWxseSBpcyBhbGwgYWJvdXQpIGNhbiBhbHNvIGJlIGRlZmluZWQgZWxzZXdoZXJl LCBpZiBNTVVTSUMgdGhpbmsgdGhleSBhcmUgdG9vIGJ1c3kuDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCkZyb206IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBNYXJ5IEJhcm5lcw0KU2VudDogMjguIGxva2FrdXV0YSAyMDE0IDE0OjQwDQpUbzogQ2hy aXN0aWFuIEdyb3Zlcw0KQ2M6IENMVUUNClN1YmplY3Q6IFJlOiBbY2x1ZV0gRlc6IGRyYWZ0LWVq emFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnIGFuZCBkcmFmdC1lanphay1tbXVzaWMtbXNy cC11c2FnZS1kYXRhLWNoYW5uZWwNCg0KT2theS4gU28sIGlmIGZvbGtzIHJlYWxseSB3YW50IHRo aXMgZm9yIENMVUUsIHRoZW4gd2UgTVVTVCBtYWtlIHN1cmUgdG8gc3VwcG9ydCB0aGUgd29yayBv biB0aGUgTU1VU0lDIFdHIG1haWxpbmcgbGlzdC4gICBBcyBJIHNhaWQsIG15IHByaW1hcnkgY29u Y2VybiBpcyB0aW1pbmcuIElmIHRoZSBjdXJyZW50IGF1dGhvciBkb2Vzbid0IGhhdmUgdGhlIGN5 Y2xlcyAob3IgbmVlZHMgaGVscCksIHdvdWxkIGFueW9uZSBoZXJlIGJlIHdpbGxpbmcgdG8gc3Rl cCBpbiBhcyBhIGNvLWF1dGhvciAoaWYgdGhlIGRvYyBpcyBhZ3JlZWQgYXMgYSBXRyBkb2N1bWVu dCkgdG8gZW5zdXJlIHRoZSB3b3JrIGFjdHVhbGx5IGdldHMgZG9uZT8NCg0KVGhhbmtzLA0KTWFy eQ0KDQpPbiBNb24sIE9jdCAyNywgMjAxNCBhdCA3OjMyIFBNLCBDaHJpc3RpYW4gR3JvdmVzIDxD aHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbTxtYWlsdG86Q2hyaXN0aWFuLkdyb3Zlc0BudGVj em9uZS5jb20+PiB3cm90ZToNCkxpa2UgQ2hyaXN0ZXIsIEkgYWxzbyB0aGluayB0aGUgbWVjaGFu aXNtIHdvdWxkIGJlIHVzZWZ1bC4gQWN0dWFsbHkgSSB0aGluayBpdHMgZXNzZW50aWFsIHdoZW4g aXQgY29tZXMgdG8gZW5kcG9pbnRzIChlc3BlY2lhbGx5IGdhdGV3YXlzKSBzdXBwb3J0aW5nIG11 bHRpcGxlIHByb3RvY29scyBpbiBhIGRhdGEgY2hhbm5lbC4gU28gSSBob3BlIHRoYXQgTU1VU0lD IGRvZXMgYWNjZXB0IHRoZSBkcmFmdC4gSWYgaXQgZG9lcyBiZWNvbWUgYSBnZW5lcmFsIG1lY2hh bmlzbSBJIHRoaW5rIHdlIGhhdmUgdG8gY29uc2lkZXIgaXQgaW4gb3VyIENMVUUgd29yay4NCg0K Q2hyaXN0aWFuDQoNCk9uIDI4LzEwLzIwMTQgNjowNSBBTSwgTWFyeSBCYXJuZXMgd3JvdGU6DQpX aGVuIHdlIGRpc2N1c3NlZCB0aGlzIGF0IElFVEYtOTAsIHdlIHNhaWQgdGhhdCB3ZSB3b3VsZCBj b25zaWRlciBpdCBpZiB0aGUgdXBkYXRlZCBkb2N1bWVudCB3YXMgc3VibWl0dGVkIG5vIGxhdGVy IHRoYW4gU2VwdGVtYmVyIDFzdCAocGVyIHRoZSBtaW51dGVzKS4gIE9mIGNvdXJzZSwgdGhhdCBk YXRlIHdhc24ndCBtZXQuICBNeSBzdWdnZXN0aW9uIGlzIHRoYXQgaWYgdGhlcmUgaXMgY29uc2Vu c3VzIHRvIGFkb3B0IHRoaXMgYXMgYW4gTU1VU0lDIFdHIGRlbGl2ZXJhYmxlLCB3ZSBjb3VsZCBh ZGQgYSByZWZlcmVuY2UuIEJVVCwgSSB3b3VsZCBzdGlsbCBiZSBjb25jZXJuZWQgYWJvdXQgZGVs YXlzIGluIHRoYXQgd29yayB0aGF0IHdvdWxkIHJlc3VsdCBpbiBDTFVFIGRvY3VtZW50cyBzaXR0 aW5nIGluIHRoZSBSRkMgZWRpdG9yJ3MgcXVldWUgd2FpdGluZyBmb3IgdGhhdCBkb2N1bWVudC4N Cg0KQXMgYW4gaW5kaXZpZHVhbCwgY29uc2lkZXJpbmcgdGhlIG92ZXJhbGwgcGFjZSBvZiB0aGUg d29yayBvbiB0aGF0IGRvY3VtZW50IHRodXMgZmFyLCBJIHdvdWxkIGJlIHF1aXRlIHdvcnJpZWQg YWJvdXQgYWRkaW5nIHRoYXQgYXMgYSBkZXBlbmRlbmN5Lg0KDQpSZWdhcmRzLA0KTWFyeS4NCg0K T24gTW9uLCBPY3QgMjcsIDIwMTQgYXQgMToyNiBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPiA8bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4+IHdyb3RlOg0KDQogICAgRllJLA0KDQogICAg S2VpdGggaGFzIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBTRFAtZGF0YS1jaGFubmVs LW5lZyBkcmFmdC4NCg0KICAgIFBlcnNvbmFsbHkgSSB0aGluayB0aGUgbWVjaGFuaXNtIHdvdWxk IGJlIHVzZWZ1bCwgYnV0IEkgdGhpbmsgaXQNCiAgICB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYSAi Q0xVRSBvcGluaW9uIiBhbHNvLiBDdXJyZW50bHkgd2Ugb25seQ0KICAgIGhhdmUgYW4gZWRpdG9y J3Mgbm90ZSBzYXlpbmcgdGhhdCB3ZSBtYXkgY29uc2lkZXIgdGhlIG1lY2hhbmlzbQ0KICAgIGRl cGVuZGluZyBvbiBob3cgaXQgcHJvZ3Jlc3Nlcy4gQnV0LCBhcyB3ZSBrbm93LCBub3RoaW5nDQog ICAgcHJvZ3Jlc3NlcyBieSBpdHNlbGYgaW4gSUVURiwgc28gdGhlIHF1ZXN0aW9uIGlzIHdoZXRo ZXIgd2Ugc2hhbGwNCiAgICBzYXkgIkNMVUUgaGFzIGFuIGludGVyZXN0IGluIHRoaXMgbWVjaGFu aXNtLCBhbmQgd291bGQgbGlrZSBpdCB0bw0KICAgIG1vdmUgZm9yd2FyZCIuDQoNCiAgICBSZWdh cmRzLA0KDQogICAgQ2hyaXN0ZXINCg0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CiAgICBGcm9tOiBtbXVzaWMgW21haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+DQogICAgPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc+Pl0gT24gQmVoYWxmIE9mIERSQUdF LCBLZWl0aCAoS2VpdGgpDQogICAgU2VudDogMjcgT2N0b2JlciAyMDE0IDE2OjM5DQogICAgVG86 IG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPiA8bWFpbHRvOm1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCiAgICBTdWJqZWN0OiBbTU1VU0lDXSBk cmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQNCiAgICBkcmFmdC1lanph ay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwNCg0KICAgIEJhc2VkIG9uIHRoZSBkaXNj dXNzaW9uIG9uIGxpc3Qgb3ZlciB0aGUgbGFzdCBmZXcgZGF5cywgSSBoYXZlDQogICAgc3VibWl0 dGVkIHJldmlzZWQgdmVyc2lvbnMgb2YgdGhlIHR3byBTRFAgbmVnb3RpYXRpb24gb3ZlciBkYXRh DQogICAgY2hhbm5lbCBkcmFmdHMgYXMgZm9sbG93czoNCg0KICAgIEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMi50eHQNCiAgICBo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtlaXRoIERyYWdlIGFuZCBwb3N0ZWQg dG8gdGhlDQogICAgSUVURiByZXBvc2l0b3J5Lg0KDQogICAgTmFtZTogICAgICAgICAgIGRyYWZ0 LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnDQogICAgUmV2aXNpb246ICAgICAgIDAy DQogICAgVGl0bGU6ICAgICAgICAgIFNEUC1iYXNlZCAiU0NUUCBvdmVyIERUTFMiIGRhdGEgY2hh bm5lbCBuZWdvdGlhdGlvbg0KICAgIERvY3VtZW50IGRhdGU6ICAyMDE0LTEwLTI3DQogICAgR3Jv dXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOiAgICAgICAgICAy Mg0KICAgIFVSTDoNCiAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMi50eHQNCiAgICBTdGF0dXM6DQog ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2ljLWRh dGEtY2hhbm5lbC1zZHBuZWcvDQogICAgSHRtbGl6ZWQ6DQogICAgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMDINCiAgICBE aWZmOg0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWVqemFrLW1t dXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAyDQoNCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGUg UmVhbC1UaW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmcN CiAgICBncm91cCBpcw0KICAgICAgIGNoYXJnZWQgdG8gcHJvdmlkZSBwcm90b2NvbHMgdG8gc3Vw cG9ydCBkaXJlY3QgaW50ZXJhY3RpdmUgcmljaA0KICAgICAgIGNvbW11bmljYXRpb25zIHVzaW5n IGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEgYmV0d2VlbiB0d28gcGVlcnMnIHdlYi0NCiAgICAgICBi cm93c2Vycy4gIEZvciB0aGUgc3VwcG9ydCBvZiBkYXRhIGNvbW11bmljYXRpb24sIHRoZSBSVENX ZWINCiAgICB3b3JraW5nDQogICAgICAgZ3JvdXAgaGFzIGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0 aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRhDQogICAgICAgY2hhbm5lbHMgb3ZlciBT Q1RQLCB3aGVyZSBlYWNoIGRhdGEgY2hhbm5lbCBtaWdodCBiZSB1c2VkIHRvDQogICAgICAgdHJh bnNwb3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkIHN1Yi1wcm90b2NvbHMuIERhdGEgY2hhbm5l bCBzZXR1cA0KICAgICAgIGNhbiBiZSBkb25lIHVzaW5nIGVpdGhlciB0aGUgaW50ZXJuYWwgaW4t YmFuZCBiYW5kIChhbHNvDQogICAgcmVmZXJyZWQgdG8NCiAgICAgICBhcyAnaW50ZXJuYWwnIGZv ciB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQpIFdlYlJUQyBEYXRhIENoYW5uZWwNCiAgICAgICBF c3RhYmxpc2htZW50IFByb3RvY29sIG9yIHNvbWUgZXh0ZXJuYWwgb3V0LW9mLWJhbmQgc2ltcGx5 IHJlZmVycmVkDQogICAgICAgdG8gYXMgJ2V4dGVybmFsIG5lZ290aWF0aW9uJyBpbiB0aGUgcmVz dCBvZiB0aGUgZG9jdW1lbnQgLiBUaGlzDQogICAgICAgZG9jdW1lbnQgc3BlY2lmaWVzIGhvdyB0 aGUgU0RQIG9mZmVyL2Fuc3dlciBleGNoYW5nZSBjYW4gYmUgdXNlZCB0bw0KICAgICAgIGFjaGll dmUgc3VjaCBhbiBleHRlcm5hbCBuZWdvdGlhdGlvbi4gIEV2ZW4gdGhvdWdoIGRhdGENCiAgICBj aGFubmVscyBhcmUNCiAgICAgICBkZXNpZ25lZCBmb3IgUlRDV2ViIHVzZSBpbml0aWFsbHkgdGhl eSBtYXkgYmUgdXNlZCBieSBvdGhlcg0KICAgIHByb3RvY29scw0KICAgICAgIGxpa2UsIGJ1dCBu b3QgbGltaXRlZCB0bywgdGhlIENMVUUgcHJvdG9jb2wuICBUaGlzIGRvY3VtZW50IGlzDQogICAg ICAgaW50ZW5kZWQgdG8gYmUgdXNlZCB3aGVyZXZlciBkYXRhIGNoYW5uZWxzIGFyZSB1c2VkLg0K DQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwNCiAgICBkcmFmdC1lanphay1tbXVzaWMtbXNy cC11c2FnZS1kYXRhLWNoYW5uZWwtMDEudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBLZWl0aCBEcmFnZSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYgcmVwb3Np dG9yeS4NCg0KICAgIE5hbWU6ICBkcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNo YW5uZWwNCiAgICBSZXZpc2lvbjogICAgICAgMDENCiAgICBUaXRsZTogICAgICAgICAgTVNSUCBv dmVyIFNDVFAvRFRMUyBkYXRhIGNoYW5uZWxzDQogICAgRG9jdW1lbnQgZGF0ZTogIDIwMTQtMTAt MjcNCiAgICBHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQogICAgUGFnZXM6 ICAgICAgICAgIDExDQogICAgVVJMOg0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWVqemFrLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbC0wMS50eHQN CiAgICBTdGF0dXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt ZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLw0KICAgIEh0bWxpemVkOg0KICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVqemFrLW1tdXNpYy1tc3JwLXVzYWdl LWRhdGEtY2hhbm5lbC0wMQ0KICAgIERpZmY6DQogICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTAxDQoN CiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIE1l c3NhZ2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbA0KICAgIChNU1JQKQ0KICAgICAgIGNhbiBiZSBp bnN0YW50aWF0ZWQgYXMgYSBkYXRhIGNoYW5uZWwgc3ViLXByb3RvY29sLCB1c2luZyB0aGUNCiAg ICB0aGUgU0RQDQogICAgICAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlLWJhc2VkIGV4dGVybmFsIG5l Z290aWF0aW9uIGRlZmluZWQgaW4NCiAgICAgICBbSS1ELmVqemFrLW1tdXNpYy1kYXRhLWNoYW5u ZWwtc2RwbmVnXS4gIFR3byBuZXR3b3JrIGNvbmZpZ3VyYXRpb25zDQogICAgICAgYXJlIGRvY3Vt ZW50ZWQ6IGEgV2ViUlRDIGVuZC10by1lbmQgY29uZmlndXJhdGlvbiAoY29ubmVjdGluZyB0d28N CiAgICAgICBNU1JQIG92ZXIgZGF0YSBjaGFubmVsIGVuZHBvaW50cyksIGFuZCBhIGdhdGV3YXkg Y29uZmlndXJhdGlvbg0KICAgICAgIChjb25uZWN0aW5nIGFuIE1TUlAgb3ZlciBkYXRhIGNoYW5u ZWwgZW5kcG9pbnQgd2l0aCBhbiBNU1JQDQogICAgb3ZlciBUQ1ANCiAgICAgICBlbmRwb2ludCku DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBtbXVzaWMgbWFpbGluZyBsaXN0DQogICAgbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNA aWV0Zi5vcmc+IDxtYWlsdG86bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ Pg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQoNCiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGNs dWUgbWFpbGluZyBsaXN0DQogICAgY2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4g PG1haWx0bzpjbHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPj4NCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNsdWUgbWFpbGluZyBsaXN0DQpj bHVlQGlldGYub3JnPG1haWx0bzpjbHVlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZzxtYWlsdG86 Y2x1ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1 ZQ0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4D0AEBESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB3b3VsZCBiZSB3aWxsaW5nIHRvIGhlbHAgdGhlIGF1dGhvcihzKSwgaWYgdGhleSBu ZWVkIGhlbHAgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9mIGNvdXJzZSwgU0RQIGF0dHJpYnV0ZXMgKHdoaWNoIHRo ZSBkcmFmdCB0ZWNobmljYWxseSBpcyBhbGwgYWJvdXQpIGNhbiBhbHNvIGJlIGRlZmluZWQgZWxz ZXdoZXJlLCBpZiBNTVVTSUMgdGhpbmsgdGhleSBhcmUgdG9vIGJ1c3kuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk1hcnkgQmFybmVzPGJyPg0KPGI+U2VudDo8L2I+IDI4LiBsb2tha3V1dGEgMjAx NCAxNDo0MDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0aWFuIEdyb3Zlczxicj4NCjxiPkNjOjwvYj4g Q0xVRTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2NsdWVdIEZXOiBkcmFmdC1lanphay1tbXVz aWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2Ut ZGF0YS1jaGFubmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2theS4g U28sIGlmIGZvbGtzIHJlYWxseSB3YW50IHRoaXMgZm9yIENMVUUsIHRoZW4gd2UgTVVTVCBtYWtl IHN1cmUgdG8gc3VwcG9ydCB0aGUgd29yayBvbiB0aGUgTU1VU0lDIFdHIG1haWxpbmcgbGlzdC4g Jm5ic3A7IEFzIEkgc2FpZCwgbXkgcHJpbWFyeSBjb25jZXJuIGlzIHRpbWluZy4gSWYgdGhlIGN1 cnJlbnQgYXV0aG9yIGRvZXNuJ3QgaGF2ZSB0aGUgY3ljbGVzIChvciBuZWVkcyBoZWxwKSwgd291 bGQgYW55b25lDQogaGVyZSBiZSB3aWxsaW5nIHRvIHN0ZXAgaW4gYXMgYSBjby1hdXRob3IgKGlm IHRoZSBkb2MgaXMgYWdyZWVkIGFzIGEgV0cgZG9jdW1lbnQpIHRvIGVuc3VyZSB0aGUgd29yayBh Y3R1YWxseSBnZXRzIGRvbmU/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXJ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDI3LCAyMDE0IGF0IDc6MzIgUE0sIENocmlzdGlhbiBH cm92ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaWtlIENocmlzdGVyLCBJ IGFsc28gdGhpbmsgdGhlIG1lY2hhbmlzbSB3b3VsZCBiZSB1c2VmdWwuIEFjdHVhbGx5IEkgdGhp bmsgaXRzIGVzc2VudGlhbCB3aGVuIGl0IGNvbWVzIHRvIGVuZHBvaW50cyAoZXNwZWNpYWxseSBn YXRld2F5cykgc3VwcG9ydGluZyBtdWx0aXBsZSBwcm90b2NvbHMgaW4gYSBkYXRhIGNoYW5uZWwu IFNvIEkgaG9wZSB0aGF0IE1NVVNJQyBkb2VzIGFjY2VwdCB0aGUgZHJhZnQuIElmDQogaXQgZG9l cyBiZWNvbWUgYSBnZW5lcmFsIG1lY2hhbmlzbSBJIHRoaW5rIHdlIGhhdmUgdG8gY29uc2lkZXIg aXQgaW4gb3VyIENMVUUgd29yay48YnI+DQo8YnI+DQpDaHJpc3RpYW48YnI+DQo8YnI+DQpPbiAy OC8xMC8yMDE0IDY6MDUgQU0sIE1hcnkgQmFybmVzIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+V2hlbiB3ZSBkaXNjdXNzZWQgdGhpcyBhdCBJRVRGLTkwLCB3ZSBz YWlkIHRoYXQgd2Ugd291bGQgY29uc2lkZXIgaXQgaWYgdGhlIHVwZGF0ZWQgZG9jdW1lbnQgd2Fz IHN1Ym1pdHRlZCBubyBsYXRlciB0aGFuIFNlcHRlbWJlciAxc3QgKHBlciB0aGUgbWludXRlcyku Jm5ic3A7IE9mIGNvdXJzZSwgdGhhdCBkYXRlIHdhc24ndCBtZXQuJm5ic3A7IE15IHN1Z2dlc3Rp b24gaXMgdGhhdCBpZiB0aGVyZSBpcyBjb25zZW5zdXMgdG8NCiBhZG9wdCB0aGlzIGFzIGFuIE1N VVNJQyBXRyBkZWxpdmVyYWJsZSwgd2UgY291bGQgYWRkIGEgcmVmZXJlbmNlLiBCVVQsIEkgd291 bGQgc3RpbGwgYmUgY29uY2VybmVkIGFib3V0IGRlbGF5cyBpbiB0aGF0IHdvcmsgdGhhdCB3b3Vs ZCByZXN1bHQgaW4gQ0xVRSBkb2N1bWVudHMgc2l0dGluZyBpbiB0aGUgUkZDIGVkaXRvcidzIHF1 ZXVlIHdhaXRpbmcgZm9yIHRoYXQgZG9jdW1lbnQuPGJyPg0KPGJyPg0KQXMgYW4gaW5kaXZpZHVh bCwgY29uc2lkZXJpbmcgdGhlIG92ZXJhbGwgcGFjZSBvZiB0aGUgd29yayBvbiB0aGF0IGRvY3Vt ZW50IHRodXMgZmFyLCBJIHdvdWxkIGJlIHF1aXRlIHdvcnJpZWQgYWJvdXQgYWRkaW5nIHRoYXQg YXMgYSBkZXBlbmRlbmN5Ljxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KTWFyeS48YnI+DQo8YnI+ DQpPbiBNb24sIE9jdCAyNywgMjAxNCBhdCAxOjI2IFBNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsmZ3Q7DQogd3JvdGU6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBGWUksPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBLZWl0 aCBoYXMgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIFNEUC1kYXRhLWNoYW5uZWwtbmVn IGRyYWZ0Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUGVyc29uYWxseSBJIHRoaW5rIHRoZSBt ZWNoYW5pc20gd291bGQgYmUgdXNlZnVsLCBidXQgSSB0aGluayBpdDxicj4NCiZuYnNwOyAmbmJz cDsgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgJnF1b3Q7Q0xVRSBvcGluaW9uJnF1b3Q7IGFsc28u IEN1cnJlbnRseSB3ZSBvbmx5PGJyPg0KJm5ic3A7ICZuYnNwOyBoYXZlIGFuIGVkaXRvcidzIG5v dGUgc2F5aW5nIHRoYXQgd2UgbWF5IGNvbnNpZGVyIHRoZSBtZWNoYW5pc208YnI+DQombmJzcDsg Jm5ic3A7IGRlcGVuZGluZyBvbiBob3cgaXQgcHJvZ3Jlc3Nlcy4gQnV0LCBhcyB3ZSBrbm93LCBu b3RoaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBwcm9ncmVzc2VzIGJ5IGl0c2VsZiBpbiBJRVRGLCBz byB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBzaGFsbDxicj4NCiZuYnNwOyAmbmJzcDsgc2F5 ICZxdW90O0NMVUUgaGFzIGFuIGludGVyZXN0IGluIHRoaXMgbWVjaGFuaXNtLCBhbmQgd291bGQg bGlrZSBpdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgbW92ZSBmb3J3YXJkJnF1b3Q7Ljxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgUmVnYXJkcyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IENocmlz dGVyPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZuYnNwOyAmbmJzcDsgRnJvbTogbW11c2ljIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDtdIE9uIEJlaGFsZiBPZiBEUkFHRSwgS2VpdGggKEtlaXRoKTxi cj4NCiZuYnNwOyAmbmJzcDsgU2VudDogMjcgT2N0b2JlciAyMDE0IDE2OjM5PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgVG86 IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNA aWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyBTdWJqZWN0OiBbTU1VU0lDXSBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5l ZyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IGRyYWZ0LWVqemFrLW1tdXNpYy1tc3JwLXVzYWdlLWRh dGEtY2hhbm5lbDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQmFzZWQgb24gdGhlIGRpc2N1c3Np b24gb24gbGlzdCBvdmVyIHRoZSBsYXN0IGZldyBkYXlzLCBJIGhhdmU8YnI+DQombmJzcDsgJm5i c3A7IHN1Ym1pdHRlZCByZXZpc2VkIHZlcnNpb25zIG9mIHRoZSB0d28gU0RQIG5lZ290aWF0aW9u IG92ZXIgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDsgY2hhbm5lbCBkcmFmdHMgYXMgZm9sbG93czo8 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1lanph ay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMi50eHQ8YnI+DQombmJzcDsgJm5ic3A7IGhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VpdGggRHJhZ2UgYW5kIHBvc3RlZCB0 byB0aGU8YnI+DQombmJzcDsgJm5ic3A7IElFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IE5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtk cmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZzxicj4NCiZuYnNwOyAmbmJzcDsg UmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDI8YnI+DQombmJzcDsgJm5ic3A7 IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU0RQLWJhc2VkICZxdW90 O1NDVFAgb3ZlciBEVExTJnF1b3Q7IGRhdGEgY2hhbm5lbCBuZWdvdGlhdGlvbjxicj4NCiZuYnNw OyAmbmJzcDsgRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNC0xMC0yNzxicj4NCiZuYnNwOyAmbmJz cDsgR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1 Ym1pc3Npb248YnI+DQombmJzcDsgJm5ic3A7IFBhZ2VzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgMjI8YnI+DQombmJzcDsgJm5ic3A7IFVSTDo8YnI+DQombmJzcDsgJm5ic3A7 IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWVqemFr LW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAyLnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZWp6YWstbW11c2ljLWRhdGEt Y2hhbm5lbC1zZHBuZWctMDIudHh0PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgU3RhdHVzOjxicj4N CiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcvIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1lanphay1tbXVzaWMtZGF0 YS1jaGFubmVsLXNkcG5lZy88L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyBIdG1saXplZDo8YnI+DQom bmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVq emFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNk cG5lZy0wMjwvYT48YnI+DQombmJzcDsgJm5ic3A7IERpZmY6PGJyPg0KJm5ic3A7ICZuYnNwOyA8 YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1lanphay1tbXVz aWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBu ZWctMDI8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBYnN0cmFjdDo8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgUmVhbC1UaW1lIENvbW11bmljYXRpb24gaW4gV0VCLWJy b3dzZXJzIChSVENXZWIpIHdvcmtpbmc8YnI+DQombmJzcDsgJm5ic3A7IGdyb3VwIGlzPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhcmdlZCB0byBwcm92aWRlIHByb3RvY29scyB0 byBzdXBwb3J0IGRpcmVjdCBpbnRlcmFjdGl2ZSByaWNoPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y29tbXVuaWNhdGlvbnMgdXNpbmcgYXVkaW8sIHZpZGVvLCBhbmQgZGF0YSBiZXR3 ZWVuIHR3byBwZWVycycgd2ViLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jyb3dz ZXJzLiZuYnNwOyBGb3IgdGhlIHN1cHBvcnQgb2YgZGF0YSBjb21tdW5pY2F0aW9uLCB0aGUgUlRD V2ViPGJyPg0KJm5ic3A7ICZuYnNwOyB3b3JraW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Z3JvdXAgaGFzIGluIHBhcnRpY3VsYXIgZGVmaW5lZCB0aGUgY29uY2VwdCBvZiBiaS1k aXJlY3Rpb25hbCBkYXRhPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhbm5lbHMg b3ZlciBTQ1RQLCB3aGVyZSBlYWNoIGRhdGEgY2hhbm5lbCBtaWdodCBiZSB1c2VkIHRvPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0IG90aGVyIHByb3RvY29scywgY2Fs bGVkIHN1Yi1wcm90b2NvbHMuIERhdGEgY2hhbm5lbCBzZXR1cDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2NhbiBiZSBkb25lIHVzaW5nIGVpdGhlciB0aGUgaW50ZXJuYWwgaW4tYmFu ZCBiYW5kIChhbHNvPGJyPg0KJm5ic3A7ICZuYnNwOyByZWZlcnJlZCB0bzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FzICdpbnRlcm5hbCcgZm9yIHRoZSByZXN0IG9mIHRoZSBkb2N1 bWVudCkgV2ViUlRDIERhdGEgQ2hhbm5lbDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0VzdGFibGlzaG1lbnQgUHJvdG9jb2wgb3Igc29tZSBleHRlcm5hbCBvdXQtb2YtYmFuZCBzaW1w bHkgcmVmZXJyZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0byBhcyAnZXh0ZXJu YWwgbmVnb3RpYXRpb24nIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCAuIFRoaXM8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRoZSBTRFAg b2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2VkIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7YWNoaWV2ZSBzdWNoIGFuIGV4dGVybmFsIG5lZ290aWF0aW9uLiZuYnNwOyBF dmVuIHRob3VnaCBkYXRhPGJyPg0KJm5ic3A7ICZuYnNwOyBjaGFubmVscyBhcmU8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNpZ25lZCBmb3IgUlRDV2ViIHVzZSBpbml0aWFsbHkg dGhleSBtYXkgYmUgdXNlZCBieSBvdGhlcjxicj4NCiZuYnNwOyAmbmJzcDsgcHJvdG9jb2xzPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGlrZSwgYnV0IG5vdCBsaW1pdGVkIHRvLCB0 aGUgQ0xVRSBwcm90b2NvbC4mbmJzcDsgVGhpcyBkb2N1bWVudCBpczxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2ludGVuZGVkIHRvIGJlIHVzZWQgd2hlcmV2ZXIgZGF0YSBjaGFubmVs cyBhcmUgdXNlZC48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgbmV3IHZlcnNpb24g b2YgSS1ELDxicj4NCiZuYnNwOyAmbmJzcDsgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2Ut ZGF0YS1jaGFubmVsLTAxLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBLZWl0aCBEcmFnZSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCiZuYnNw OyAmbmJzcDsgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgTmFtZTom bmJzcDsgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsPGJyPg0KJm5i c3A7ICZuYnNwOyBSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMTxicj4NCiZu YnNwOyAmbmJzcDsgVGl0bGU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNU1JQ IG92ZXIgU0NUUC9EVExTIGRhdGEgY2hhbm5lbHM8YnI+DQombmJzcDsgJm5ic3A7IERvY3VtZW50 IGRhdGU6Jm5ic3A7IDIwMTQtMTAtMjc8YnI+DQombmJzcDsgJm5ic3A7IEdyb3VwOiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJm5i c3A7ICZuYnNwOyBQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDExPGJy Pg0KJm5ic3A7ICZuYnNwOyBVUkw6PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lanphay1tbXVzaWMtbXNycC11c2Fn ZS1kYXRhLWNoYW5uZWwtMDEudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNo YW5uZWwtMDEudHh0PC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgU3RhdHVzOjxicj4NCiZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6 YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNh Z2UtZGF0YS1jaGFubmVsLzwvYT48YnI+DQombmJzcDsgJm5ic3A7IEh0bWxpemVkOjxicj4NCiZu YnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZWp6 YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1k YXRhLWNoYW5uZWwtMDE8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyBEaWZmOjxicj4NCiZuYnNwOyAm bmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZWp6 YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1lanphay1tbXVzaWMtbXNycC11 c2FnZS1kYXRhLWNoYW5uZWwtMDE8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBBYnN0cmFj dDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IHNwZWNpZmll cyBob3cgdGhlIE1lc3NhZ2UgU2Vzc2lvbiBSZWxheSBQcm90b2NvbDxicj4NCiZuYnNwOyAmbmJz cDsgKE1TUlApPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2FuIGJlIGluc3RhbnRp YXRlZCBhcyBhIGRhdGEgY2hhbm5lbCBzdWItcHJvdG9jb2wsIHVzaW5nIHRoZTxicj4NCiZuYnNw OyAmbmJzcDsgdGhlIFNEUDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mZmVyL2Fu c3dlciBleGNoYW5nZS1iYXNlZCBleHRlcm5hbCBuZWdvdGlhdGlvbiBkZWZpbmVkIGluPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0ktRC5lanphay1tbXVzaWMtZGF0YS1jaGFubmVs LXNkcG5lZ10uJm5ic3A7IFR3byBuZXR3b3JrIGNvbmZpZ3VyYXRpb25zPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YXJlIGRvY3VtZW50ZWQ6IGEgV2ViUlRDIGVuZC10by1lbmQgY29u ZmlndXJhdGlvbiAoY29ubmVjdGluZyB0d288YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtNU1JQIG92ZXIgZGF0YSBjaGFubmVsIGVuZHBvaW50cyksIGFuZCBhIGdhdGV3YXkgY29uZmln dXJhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhjb25uZWN0aW5nIGFuIE1T UlAgb3ZlciBkYXRhIGNoYW5uZWwgZW5kcG9pbnQgd2l0aCBhbiBNU1JQPGJyPg0KJm5ic3A7ICZu YnNwOyBvdmVyIFRDUDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2VuZHBvaW50KS48 YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBtbXVzaWMgbWFpbGluZyBsaXN0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2lj QGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJz cDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21t dXNpYzwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBjbHVlIG1haWxpbmcg bGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmNsdWVAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5jbHVlQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpjbHVlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2x1ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NsdWUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NsdWU8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpjbHVlIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjbHVlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y2x1ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NsdWUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KY2x1ZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86Y2x1ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNsdWVAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4D0AEBESESSMB209erics_-- From nobody Tue Oct 28 05:59:56 2014 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 CA0AD1A6F24 for ; Tue, 28 Oct 2014 05:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.439 X-Spam-Level: *** X-Spam-Status: No, score=3.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.77, 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 YGTXafyx8b1N for ; Tue, 28 Oct 2014 05:59:22 -0700 (PDT) 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 CF2D51A6F60 for ; Tue, 28 Oct 2014 05:55:55 -0700 (PDT) X-ASG-Debug-ID: 1414500950-05f2757f315f41b0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id LsCgTcKcld3HxyiW (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2014 13:55:50 +0100 (CET) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s9SCtnOm032042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 28 Oct 2014 13:55:49 +0100 Message-ID: <544F9257.1090207@unina.it> Date: Tue, 28 Oct 2014 13:55:51 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Kyzivat , "clue@ietf.org" References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt In-Reply-To: <544EA871.6010507@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1414500950 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.0043 1.0000 -1.9927 X-Barracuda-Spam-Score: -1.99 X-Barracuda-Spam-Status: No, SCORE=-1.99 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10989 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TDMuKs0PwVPSVidgyHF1oIvV_7g Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 12:59:26 -0000 Dear Paul, thank you for your review. We start to answer to your comments below. We will discuss in more detail some of your observations during the call and/or in following emails. Roberta Il 27/10/2014 21:17, Paul Kyzivat ha scritto: > I have tried to go through the key changes in the protocol document. > Here are the things I noted: > > The new definition of Advertisement now has a choice of the full adv, > or a partial adv. The partial adv starts out directly with > add/remove/... I see nothing that explicitly indicates the body that > is being modified. Looking at the example, the xpath expression > references something like "/advertisement/people", but that could > apply to *any* version of the advertisement. I guess the intent is > that it reference the "latest" one. But it seems like it would be > better to have some identifier that makes clear what is to be > modified. For instance, a reference to the sequence number of the > advertisement being updated. The intention was to update with a partial ADV just the latest sent-and-acked ADV, and not any previously sent ADV. This is text from the current version: "When an ADV sent from the MP to the MC has been ACK-ed by the MC, the MP can decide to send the next ADV in a diff format with respect to the previously sent ADV." No problem with adding a field specifying the number of the ADV to refer to, but it conveys a "redundant" information, since the ADV to refer to is always the latest sent-and-acked. If the sequence number is not the one of the latest sent-and-acked ADV, the MC should NACK the partial ADV with an ad-hoc response code. > > Why has READV been *removed*? Has something changed so that we don't > need it? (I was advocating for renaming it, not removing it.) > While reviewing the state machines, we found the message redundant in each case where in the past we thought it could be useful. It is one of the topic of the today's discussion. > * Section 4.7: > > Regarding response code numbering: is the goal to follow SIP or HTTP > numbering philosophies? Why are some errors given 3xx codes and others > 4xx codes? > Response codes are one of the listed open issues. They need to be improved to cover the possible situations. In the current version of the document, they do not follow any of the mentionend philosophies. > * Section 6: > > I have a number of comments on this section and subsections. I'll try > to be as specific as I can, but it is hard to discuss potential > changes, because everything is interconnected. It would be best if we > could have an interactive whiteboard session on this. But I doubt that > is in the cards. > > ... If the CP receives a further > OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay > in the ACTIVE state. > > Is this really the best thing to do in this case? Ignoring messages, > without even responding, can't come to any good end. I would think > that either an error response should be sent to the message, or else > the clue session should be terminated. The reason why we decided to ignore these messages while the CP is in the active state is that we stated the initiation phase is done exactly once in each CLUE session. When this phase is over (successfully concluded) , the CP moves in the ACTIVE state. There is no need to issue again OPTIONS/OPTIONS RESPONSE messages since the session is successfully negotiated in terms of the version of the protocol and the options to be used. If, for any reason, a new version & options negotiation needs to be triggered, than the application level should end the current CLUE session (CP moves to TERMINATED) and should start a new one. > > One way to handle this would be to view this as a outer state machine > that does the sending/receiving of messages and demuxing them among > OPTIONS, MP, and MC state machines. So OPTIONS messages and their > responses always go to the OPTIONS state machine, and other messages > to their respective state machines. (Messages that are not > identifiable as requests or responses destined for any of the > sub-state-machines would result is an error that closes the channel.) > > Initially, the OPTIONS state machine processes OPTIONS messages, while > the MP and MC machines consider messages to them errors. After options > processing is completed, OPTIONS messages still go to the OPTIONS > state machine, but it treats them as errors, sending a suitable error > response. Initially the MP and MC state machines treat messages to > them as errors. After the options processing is completed, one or both > of them enter a state where they process their corresponding messages. > > * Section 6.1: > > A general observation: I think it is unclear how the timing of the > arrival of messages affects this state machine. It seems unnecessarily > complex to deal with a message arriving at any time, yet it seems > impossible to avoid that possibility. The best solution I can think of > is that there should be a message queue associated with the state > machine. When the outer state machine identifies a message that should > be processed by this state machine then that message can enter the > queue. Then this state machine can process messages from that queue at > convenient times. Those times correspond to the "wait for X" states, > and the ESTABLISHED state. When in those states, you are really > waiting for a message, and then must branch on what sort of message it > is. > In general, we adopted the philosophy of keeping it simple and working. We are quite confident that we avoid hang situations with the proposed solution. We listed just the events (typically, message sent/received) triggering state transitions and we do not diagram/consider other events that should not be possible if implementing correctly the proposed state machines. > What does "retry expired"/"retry not expired" mean, and how does it > relate to "timeout". (Not just here - also in subsequent sections.) I > have the impression from past discussions that you intend that there > be some time limit or limits to be applied to the receipt of certain > expected messages, and also that there be some limited number of > retries sending messages when an expected reply has not been received. > But I don't find even that much detail in the text, and more than that > is needed to make this be a sufficient specification. (There is a > *little* bit about retry threshold in 6.2.) Without more detail I > can't even guess whether that will work adequately. > We agree that more text is needed to explain the timeout and retry mechanism. We plan to add it asap. > Next, consider > > ... CONF+ACK messages referring to out-of-date ADVs should be > ignored, i.e., they do not trigger any state transition. > > Again, ignoring messages seems like a very bad idea. It leads to > hangs. I think there must be a response to this, indicating that it > has failed. And perhaps also send a new ADV and hope the consumer gets > things straightened out after that. > The case you present here will be clarified with a sample call flow which is coherent with the current specification of the state machines. The rest of your review will be considered in following emails /disussion. Thank you again, Roberta and Simon > * Section 6.2: > > (Some of the general issues I raised above for 6.1 apply here too.) > > An MC in the WAIT FOR ADV state is waiting for an ADV coming from the > MP. If the ADV arrives ("ADV received"), the MC reaches the > PROCESSING ADV state. Otherwise, the MC is stuck in the WAIT FOR ADV > state. > > Suppose what arrives is some message other than an ADV. (I guess the > only thing that could be here is a CONF response.) If something odd > like that happens then I think it must not be just ignored. But you > can't send a response to a response. We may need another message to > report bad things. And/or maybe the channel should be torn down. > > ... If > the NACK retry expires ("retry expired"), the MC moves to the MC > TERMINATED state. > > This is a pretty serious state. I think CLUE is still enabled, but the > MC is terminated. In that state, what happens to incoming messages? > (ADVs) If they aren't responded to then bad things will happen. I > think two things are needed: (1) a NAK must still be sent, with > indication that this is a fatal error for the MC; (2) in the > TERMINATED state messages must still be accepted, with error responses > to requests. Ideally, if the MC goes to the TERMINATED state then we > want the MP at the other end to also go to that state. > > When the SDP information arrives, from the ADV RECEIVED or the ADV > ACKED state the MC switches to the READY TO CONF state. When the > CONF request is ready, the MC sends it and moves to the TRYING state. > If the ADV has not yet been sent, the MC can piggyback the ACK > message inside the CONF request. > ... > When the MC is in the SDP O/A state, the telepresence session > configuration has been set up at the CLUE application level according > to the MC's preferences. Both the MP and the MC have agreed on (and > are aware of) the media streams to be exchanged within the call. In > this state, the MC waits for the SDP offer coming from the MP. As > soon as it arrives, the MC replies with an SDP answer. > > I wonder if the first of these paragraphs is in the wrong place, or is > simply old info no longer intended to be here. For instance, I see no > ADV RECEIVED or ADV ACKED states. And it seems in an odd place in the > flow of text. > > In any case, waiting for SDP may present similar issues to waiting for > a message. (SDP arrival is far too unsynchronized from the state > machine to depend on it arriving exactly when you want it.) So it may > be that the state machine needs a queue for this that can be queried > from the state that cares. ISTM more consideration is needed of the > impact of SDP changes on this state machine. > > Regarding initiation of an O/A - it certainly can be the case that a > new O/A is not needed. I see no provision for that possibility. > > Perhaps O/A should be handled with a separate state machine - loosely > coupled (by events) to both MC and MP machines. (So that a newly > accepted CONF triggers an event to the O/A state machine, causing it > to analyze the most recent configuration of both MC and MP, and decide > if a new offer should be sent.) Considering that both ends are likely > to have both an MC and an MP, it seems like it might be tricky to > decide who should send a new offer. > > * Section 11.4: DNS Registrations > > Why do we need any DNS registrations??? > > We want a feature tag and an SDP grouping tag, but the signaling draft > deals with those. > > * I didn't yet review the examples. > > Thanks, > Paul > > On 10/24/14 9:42 AM, Roberta Presta wrote: >> Dear all, >> we have just uploaded the new version of the protocol document to be >> discussed in the next call. >> In the following the diff with version 01. >> Best regards, >> >> Roberta >> >> o The diff mechanism for the ADV message has been introduced. >> >> o READV and READV RESPONSE message have been both removed. >> >> o The state machines have been deeply reviewed and changed. >> >> o References: references have been updated and splitted into >> Informative references and Normative references as in framework >> v17. >> >> o Schema: changed in , >> in >> >> o Terminology: many definitions added. Response codes updated. >> >> >> >> >> >> Il 24/10/2014 15:10, internet-drafts@ietf.org ha scritto: >>> 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 >>> Authors : Roberta Presta >>> Simon Pietro Romano >>> Filename : draft-ietf-clue-protocol-02.txt >>> Pages : 59 >>> Date : 2014-10-24 >>> >>> Abstract: >>> The CLUE protocol is an application protocol conceived for the >>> description and negotiation of a CLUE telepresence session. The >>> design of the CLUE protocol takes into account the requirements and >>> the framework defined, respectively, in >>> [I-D.ietf-clue-framework] and >>> [I-D.ietf-clue-telepresence-requirements]. The companion document >>> [I-D.ietf-clue-signaling] delves into CLUE signaling details, as >>> well >>> as on the SIP/SDP session establishment phase. CLUE messages flow >>> upon the CLUE data channel, based on reliable and ordered SCTP over >>> DTLS transport, as described in [I-D.ietf-clue-datachannel]. >>> Message >>> details, together with the behavior of CLUE Participants acting as >>> Media Providers and/or Media Consumers, are herein discussed. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-clue-protocol-02 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Oct 28 06:11:18 2014 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 8C3D01A878A for ; Tue, 28 Oct 2014 06:11:09 -0700 (PDT) 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 zO3ndm3ZUZ62 for ; Tue, 28 Oct 2014 06:10:59 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC231A87AB for ; Tue, 28 Oct 2014 06:10:07 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id n15so570722lbi.3 for ; Tue, 28 Oct 2014 06:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SkVKJ0XHXwKQb4JA7RYtp0rII301mNyDD6LTD/CaBTM=; b=Hr1gXhKAMlA1rCYRx0Uiah3DEzjQChTfZ1FzgInpQXpI0q3Z+ve4kqzsQsvi9YZWv7 Rww5MF8W7NMmpUxOv7GyQ09DUkAXw0scBQwUuUdTZhy5NsHYbnuLU7rnBFxhUvVW+YlQ CFZdtOFI0DQWXNnnzYmMeCBVj9nWox/+3RJJHhBSZnhauUoeI74v5qLwaRQwnwAp51fi mrFoIKjfZX5Ph3Hbesz0s5VS5CMrhFWUY4xdYQQ0xGpIlHG5wJNKIj8sEH/TiLdm5Yvl 15DfSixl+v83MdqcJdBE/0SSjD7ianTULtaCkYJ8Pml1fGeU2CCMyu0Z3JjqjYgjTQcV q1HQ== MIME-Version: 1.0 X-Received: by 10.112.139.196 with SMTP id ra4mr1256975lbb.95.1414501805935; Tue, 28 Oct 2014 06:10:05 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 06:10:05 -0700 (PDT) Date: Tue, 28 Oct 2014 08:10:05 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c33fccad4f6b05067b5de4 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TPX-B6CiyPxngJdGtu9WiKixNbg Subject: [clue] CLUE Design team meeting is on today 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, 28 Oct 2014 13:11:09 -0000 --001a11c33fccad4f6b05067b5de4 Content-Type: text/plain; charset=UTF-8 We are currently discussing the protocol. There are only 4 of us on the call - 2 chairs, the presenter (Roberta) and Mark. (Note: that one person (Rob) did send his regrets). It would be a good idea if others could join so we're not just having to repeat this in HNL. Thanks, Mary --001a11c33fccad4f6b05067b5de4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We are currently discussing the protocol.=C2=A0 There are = only 4 of us on the call - 2 chairs, the presenter (Roberta) and Mark. =C2= =A0(Note: that one person (Rob) did send his regrets). =C2=A0 It would be a= good idea if others could join so we're not just having to repeat this= in HNL.

Thanks,
Mary
--001a11c33fccad4f6b05067b5de4-- From nobody Tue Oct 28 06:21:15 2014 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 319C11A87AA for ; Tue, 28 Oct 2014 06:21:12 -0700 (PDT) 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 8ZnU2YEc5X5z for ; Tue, 28 Oct 2014 06:21:10 -0700 (PDT) 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 F07001A874E for ; Tue, 28 Oct 2014 06:20:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-69-544f9836c23a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.31.04231.6389F445; Tue, 28 Oct 2014 14:20:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Tue, 28 Oct 2014 14:20:53 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] CLUE Design team meeting is on today Thread-Index: AQHP8rCq7rZ0Kpd/hE2DJQsnu7e1upxFfmNQ Date: Tue, 28 Oct 2014 13:20:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D0C03ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvja7ZDP8Qg8k9Ahb7T11mtvi8fz+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVxru8rW8EUnYpnK08zNjB+0Opi5OCQEDCR eLqloouRE8gUk7hwbz1bFyMXh5DAEUaJyxs3MkM4Sxgl7n28wgjSwCZgIdH9TxukQUTASeLC y/csILYwUHjK1OksEHFLiQ+vl7ND2EYS3SsOgsVZBFQlDv9ewQxi8wr4Sqx99QDMFhIIkLi+ 7B6YzSkQKPFk7VMwmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghflGUWN4v B1GeL/H96SRWiFWCEidnPmGZwCgyC8mkWUjKZiEpmwU0iVlAU2L9Ln2IEkWJKd0P2SFsDYnW OXPZkcUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMqINbfuvuYFz92vEQowAHoxIP 7wY2/xAh1sSy4srcQ4zSHCxK4ryLzs0LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYeuFB R/NcUbnnTmW3Hp7KCo7+sqTxDZt+vvn7vXsSl7mXm/To3P5/7oC8rN+FB3FOPKueH9x7S6Je LCfw/4eaC5k+ZXLaWrk1XCtath6XuFR39Izjc1mbnV8V+h1NnCZ6FDHNtlzj9iyq5mayReny R66K/YI1yVvPRqqE8l1uarxpkdX4WUeJpTgj0VCLuag4EQBiWPxOiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7PCmag2zaGC4rw6813WZEUvZ2sA Subject: Re: [clue] CLUE Design team meeting is on today 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, 28 Oct 2014 13:21:12 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D0C03ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2Ugc3dpdGNoZWQgdG8gd2ludGVyIHRpbWUgYSBmZXcgZGF5cyBhZ28sIHNvIEkgdGhvdWdodCB3 ZSB3b27igJl0IGJlZ2luIHVudGlsIG9uZSBob3Vy4oCmDQoNCknigJlsbCBjYWxsIGluLg0KDQpG cm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy eSBCYXJuZXMNClNlbnQ6IDI4LiBsb2tha3V1dGEgMjAxNCAxNToxMA0KVG86IENMVUUNClN1Ympl Y3Q6IFtjbHVlXSBDTFVFIERlc2lnbiB0ZWFtIG1lZXRpbmcgaXMgb24gdG9kYXkNCg0KV2UgYXJl IGN1cnJlbnRseSBkaXNjdXNzaW5nIHRoZSBwcm90b2NvbC4gIFRoZXJlIGFyZSBvbmx5IDQgb2Yg dXMgb24gdGhlIGNhbGwgLSAyIGNoYWlycywgdGhlIHByZXNlbnRlciAoUm9iZXJ0YSkgYW5kIE1h cmsuICAoTm90ZTogdGhhdCBvbmUgcGVyc29uIChSb2IpIGRpZCBzZW5kIGhpcyByZWdyZXRzKS4g ICBJdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSBpZiBvdGhlcnMgY291bGQgam9pbiBzbyB3ZSdyZSBu b3QganVzdCBoYXZpbmcgdG8gcmVwZWF0IHRoaXMgaW4gSE5MLg0KDQpUaGFua3MsDQpNYXJ5DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4D0C03ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHN3aXRj aGVkIHRvIHdpbnRlciB0aW1lIGEgZmV3IGRheXMgYWdvLCBzbyBJIHRob3VnaHQgd2Ugd29u4oCZ dCBiZWdpbiB1bnRpbCBvbmUgaG91cuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIGNhbGwgaW4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBjbHVlIFttYWlsdG86Y2x1ZS1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJ5IEJhcm5lczxicj4NCjxi PlNlbnQ6PC9iPiAyOC4gbG9rYWt1dXRhIDIwMTQgMTU6MTA8YnI+DQo8Yj5Ubzo8L2I+IENMVUU8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW2NsdWVdIENMVUUgRGVzaWduIHRlYW0gbWVldGluZyBpcyBv biB0b2RheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFyZSBjdXJy ZW50bHkgZGlzY3Vzc2luZyB0aGUgcHJvdG9jb2wuJm5ic3A7IFRoZXJlIGFyZSBvbmx5IDQgb2Yg dXMgb24gdGhlIGNhbGwgLSAyIGNoYWlycywgdGhlIHByZXNlbnRlciAoUm9iZXJ0YSkgYW5kIE1h cmsuICZuYnNwOyhOb3RlOiB0aGF0IG9uZSBwZXJzb24gKFJvYikgZGlkIHNlbmQgaGlzIHJlZ3Jl dHMpLiAmbmJzcDsgSXQgd291bGQgYmUgYSBnb29kIGlkZWEgaWYgb3RoZXJzIGNvdWxkIGpvaW4g c28gd2UncmUgbm90DQoganVzdCBoYXZpbmcgdG8gcmVwZWF0IHRoaXMgaW4gSE5MLjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFyeTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4D0C03ESESSMB209erics_-- From nobody Tue Oct 28 06:59:11 2014 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 7D4711A8831 for ; Tue, 28 Oct 2014 06:59:09 -0700 (PDT) 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 IUdU-aC6g6_R for ; Tue, 28 Oct 2014 06:59:07 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C4E1A0404 for ; Tue, 28 Oct 2014 06:59:07 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so899017wgh.34 for ; Tue, 28 Oct 2014 06:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=MN93yKh3lY+UT8Z5Si/pCfVBPYsMfTXwlfgla3fmpr0=; b=xiQBk9tlxBVj45/kGrOao+xyOimB4tAPZ/4Y3+IIRPlkmm8Ib6XAP1/earZueXRKbP nTRY/DIF6m6dSNlYUs6A7hJG26wO1Y1P//fxB7f0M6tWzXQBcindlyQe4k6qo2PIBRzF i/OkUFj/4gtJ7JB5ytCUUMlGYi9LuCx5dsdRj5o1xF2tx+3m5g25S3gnO7MkqsnBSBzj xBFXQ/DecHHItgBYlX3r4XQLm2y7h9mp0Aw4MzWkg0c7weCmBwZ880Rpa1C4e9ddltUU V+yd6Bb0hDULPiooWAwZ2DeXU1AE92m80kHiIcbT+1NvQ1Zal9K0O6h1eqT6P0W4LjqF zWBQ== X-Received: by 10.180.82.105 with SMTP id h9mr4926855wiy.62.1414504745791; Tue, 28 Oct 2014 06:59:05 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id f9sm1661234wjw.31.2014.10.28.06.59.03 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Oct 2014 06:59:04 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Mary Barnes'" , "'CLUE'" References: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> Date: Tue, 28 Oct 2014 15:59:00 +0200 Message-ID: <085c01cff2b7$55416600$ffc43200$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_085D_01CFF2C8.18CAF950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGs+83BqT5r8jvfz8aXiDUf86urAHZmdIOm8k555A= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gQq7lAtlmQjocnx8adgNQDj_gsI Subject: Re: [clue] CLUE Design team meeting is on today 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, 28 Oct 2014 13:59:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_085D_01CFF2C8.18CAF950 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Same problem,=20 Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 28 October, 2014 3:21 PM To: Mary Barnes; CLUE Subject: Re: [clue] CLUE Design team meeting is on today =20 We switched to winter time a few days ago, so I thought we won=E2=80=99t = begin until one hour=E2=80=A6 =20 I=E2=80=99ll call in. =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 28. lokakuuta 2014 15:10 To: CLUE Subject: [clue] CLUE Design team meeting is on today =20 We are currently discussing the protocol. There are only 4 of us on the = call - 2 chairs, the presenter (Roberta) and Mark. (Note: that one = person (Rob) did send his regrets). It would be a good idea if others = could join so we're not just having to repeat this in HNL. =20 Thanks, Mary ------=_NextPart_000_085D_01CFF2C8.18CAF950 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Same problem,

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer = Holmberg
Sent: 28 October, 2014 3:21 PM
To: Mary = Barnes; CLUE
Subject: Re: [clue] CLUE Design team meeting is = on today

 

We switched to winter time a few days ago, so I thought we = won=E2=80=99t begin until one hour=E2=80=A6

 

I=E2=80=99ll call in.

 

From:= = clue [mailto:clue-bounces@ietf.org] = On Behalf Of Mary Barnes
Sent: 28. lokakuuta 2014 = 15:10
To: CLUE
Subject: [clue] CLUE Design team = meeting is on today

 

We are = currently discussing the protocol.  There are only 4 of us on the = call - 2 chairs, the presenter (Roberta) and Mark.  (Note: that one = person (Rob) did send his regrets).   It would be a good idea if = others could join so we're not just having to repeat this in = HNL.

 

Thanks,

Mary

------=_NextPart_000_085D_01CFF2C8.18CAF950-- From nobody Tue Oct 28 06:59:43 2014 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 5F1E21A8831 for ; Tue, 28 Oct 2014 06:59:42 -0700 (PDT) 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 bUJoZUXnG8fl for ; Tue, 28 Oct 2014 06:59:41 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91541A1BAA for ; Tue, 28 Oct 2014 06:59:40 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gm9so667606lab.4 for ; Tue, 28 Oct 2014 06:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4CAs2tGiLAOdl38KsOFo1bds4QjZCj7Dbk8gOlp3nVw=; b=sJybyaT2tj9gsMLku4xhWBbMUleEtxEKT3LjDDNhdMbylvrIwVUHP+Jsb8/cJua0jv Yq9fHiBKJOUyUAiZY2gXY4jgQ65QFk6Wv8JqRR0hWC/Epo+cwVeixlxz7y3kLyn0bxSc ZhrLpp5cR+bm+z2aDtTH9lE4QvvWd1W3NDjsXSiDdFGSEncjCJwOOiJ+NdDE7ig0fmny Z6v08n1U9Rdc1UJWuJAzTz6EzHBFfDBRFbKx13vDwfArFMf7V2o3s9c/xk9dYecBJdGU vINULPN9gxqjPeQzd36e9zomXpb8upyqcN/+8jKQFtdKHfSnPp7/gJWfGFHSotBZUZly nsiw== MIME-Version: 1.0 X-Received: by 10.112.138.39 with SMTP id qn7mr4203731lbb.57.1414504778863; Tue, 28 Oct 2014 06:59:38 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 06:59:38 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> Date: Tue, 28 Oct 2014 08:59:38 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=089e011614ece09b5d05067c0ee4 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZzxpUR4OTV3HG-kcq1K8VYEH0eg Cc: CLUE Subject: Re: [clue] CLUE Design team meeting is on today 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, 28 Oct 2014 13:59:42 -0000 --089e011614ece09b5d05067c0ee4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh yeah, I ought to have sent a reminder about that as well. On Tue, Oct 28, 2014 at 8:20 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > We switched to winter time a few days ago, so I thought we won=E2=80=99t= begin > until one hour=E2=80=A6 > > > > I=E2=80=99ll call in. > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 28. lokakuuta 2014 15:10 > *To:* CLUE > *Subject:* [clue] CLUE Design team meeting is on today > > > > We are currently discussing the protocol. There are only 4 of us on the > call - 2 chairs, the presenter (Roberta) and Mark. (Note: that one perso= n > (Rob) did send his regrets). It would be a good idea if others could jo= in > so we're not just having to repeat this in HNL. > > > > Thanks, > > Mary > --089e011614ece09b5d05067c0ee4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh yeah, I ought to have sent a reminder about that as wel= l.

On Tue, O= ct 28, 2014 at 8:20 AM, Christer Holmberg <christer.holmberg@= ericsson.com> wrote:

We switched to winter tim= e a few days ago, so I thought we won=E2=80=99t begin until one hour=E2=80= =A6

=C2=A0

I=E2=80=99ll call in.<= /u>

=C2=A0

From: clue [ma= ilto:clue-bounce= s@ietf.org] On Behalf Of Mary Barnes
Sent: 28. lokakuuta 2014 15:10
To: CLUE
Subject: [clue] CLUE Design team meeting is on today

=C2=A0

We are currently discussing the protocol.=C2=A0 Ther= e are only 4 of us on the call - 2 chairs, the presenter (Roberta) and Mark= . =C2=A0(Note: that one person (Rob) did send his regrets). =C2=A0 It would= be a good idea if others could join so we're not just having to repeat this in HNL.

=C2=A0

Thanks,

Mary


--089e011614ece09b5d05067c0ee4-- From nobody Tue Oct 28 08:16:53 2014 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 C34111A8A81 for ; Tue, 28 Oct 2014 08:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 AdMafoAz-nHD for ; Tue, 28 Oct 2014 08:16:47 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609881A8A9A for ; Tue, 28 Oct 2014 08:16:47 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-12v.sys.comcast.net with comcast id 8fGc1p0075AAYLo01fGmKT; Tue, 28 Oct 2014 15:16:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-15v.sys.comcast.net with comcast id 8fGk1p00X3Ge9ey01fGlJl; Tue, 28 Oct 2014 15:16:46 +0000 Message-ID: <544FB35C.80706@alum.mit.edu> Date: Tue, 28 Oct 2014 11:16:44 -0400 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: Roberta Presta , "clue@ietf.org" References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> <544F9257.1090207@unina.it> In-Reply-To: <544F9257.1090207@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414509406; bh=3tVxAgyufiySg0RqcOBbHRXFVswMqM/HuGybbqu+ZIo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LdHfzqUvjsoLP/IMVnrbymn7Crt0VFfI6ihxLaRTTX2MnB71eS6L0R54MC5QjIXed Y8gh9LxCTarUQ/yYv2Twjn469S4I2tloLHzcnWDi0mf6/9xrPFMYyLoaVSkZ+W2bUF A+aMDSCvfdJUQoHzDwanC0iojyZ4A0Z9kcyzbCXvl5ou2uMViMnfe5Uenl6fbpgXcV RbzPPXkIhFgq49P4S2EqLWh4eUpFYXCxXw+b1NPEYLkr2hi1sUCeb/sR5NUNa0a1uK UeHhGvfM/aCZ7pxyLu+0BXQezn4mb5CbQF3J3ERc5e+gmYkj/l8hOSu2bR3t/0cSle s9wLauV56ETCg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wcCd394OSsHeQAWAOkvFu3F3E-E Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 15:16:51 -0000 Hi Roberta, More discussion inline. On 10/28/14 8:55 AM, Roberta Presta wrote: > Dear Paul, > thank you for your review. > We start to answer to your comments below. > We will discuss in more detail some of your observations during the call > and/or in following emails. > > Roberta > > > Il 27/10/2014 21:17, Paul Kyzivat ha scritto: >> I have tried to go through the key changes in the protocol document. >> Here are the things I noted: >> >> The new definition of Advertisement now has a choice of the full adv, >> or a partial adv. The partial adv starts out directly with >> add/remove/... I see nothing that explicitly indicates the body that >> is being modified. Looking at the example, the xpath expression >> references something like "/advertisement/people", but that could >> apply to *any* version of the advertisement. I guess the intent is >> that it reference the "latest" one. But it seems like it would be >> better to have some identifier that makes clear what is to be >> modified. For instance, a reference to the sequence number of the >> advertisement being updated. > The intention was to update with a partial ADV just the latest > sent-and-acked ADV, and not any previously sent ADV. > This is text from the current version: > "When an ADV sent from the MP to the MC has been ACK-ed by the MC, the > MP can decide to send the next ADV in a diff format with respect to the > previously sent ADV." > No problem with adding a field specifying the number of the ADV to refer > to, but it conveys a "redundant" information, since the ADV to refer to > is always the latest sent-and-acked. > If the sequence number is not the one of the latest sent-and-acked ADV, > the MC should NACK the partial ADV with an ad-hoc response code. Yes, it is redundant information, for purposes of error detection. Without it, if things get out of sync, then the diffs might be applied to the wrong version, without detecting that something is wrong. Or *eventually* the application of a diff might fail because the xpath refers to something non-existent, but it might happen so late that it is difficult to detect what went wrong. >> Why has READV been *removed*? Has something changed so that we don't >> need it? (I was advocating for renaming it, not removing it.) >> > While reviewing the state machines, we found the message redundant in > each case where in the past we thought it could be useful. It is one of > the topic of the today's discussion. Based on discussion in design team call today I agree that we don't seem to need it. BUT, I think there is something that will help to guarantee that. If a partial adv is *rejected*, then the advertiser should always send a full advertisement. >> * Section 4.7: >> >> Regarding response code numbering: is the goal to follow SIP or HTTP >> numbering philosophies? Why are some errors given 3xx codes and others >> 4xx codes? >> > Response codes are one of the listed open issues. They need to be > improved to cover the possible situations. In the current version of > the document, they do not follow any of the mentionend philosophies. >> * Section 6: >> >> I have a number of comments on this section and subsections. I'll try >> to be as specific as I can, but it is hard to discuss potential >> changes, because everything is interconnected. It would be best if we >> could have an interactive whiteboard session on this. But I doubt that >> is in the cards. >> >> ... If the CP receives a further >> OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay >> in the ACTIVE state. >> >> Is this really the best thing to do in this case? Ignoring messages, >> without even responding, can't come to any good end. I would think >> that either an error response should be sent to the message, or else >> the clue session should be terminated. > > The reason why we decided to ignore these messages while the CP is in > the active state is that we stated the initiation phase is done exactly > once in each CLUE session. > When this phase is over (successfully concluded) , the CP moves in the > ACTIVE state. > There is no need to issue again OPTIONS/OPTIONS RESPONSE messages since > the session is successfully negotiated in terms of the version of the > protocol and the options to be used. If, for any reason, a new version & > options negotiation needs to be triggered, than the application level > should end the current CLUE session (CP moves to TERMINATED) and should > start a new one. My concern is that we prevent any circumstance when we get a "hang" situation in the protocol - because a message has been dropped while the sender of that message is awaiting a response. If that situation is *always* resolved via timeouts, then maybe it is ok. Even then, actively reporting the error could result in quicker error detection. How important that is depends on how long the timeout is. >> One way to handle this would be to view this as a outer state machine >> that does the sending/receiving of messages and demuxing them among >> OPTIONS, MP, and MC state machines. So OPTIONS messages and their >> responses always go to the OPTIONS state machine, and other messages >> to their respective state machines. (Messages that are not >> identifiable as requests or responses destined for any of the >> sub-state-machines would result is an error that closes the channel.) >> >> Initially, the OPTIONS state machine processes OPTIONS messages, while >> the MP and MC machines consider messages to them errors. After options >> processing is completed, OPTIONS messages still go to the OPTIONS >> state machine, but it treats them as errors, sending a suitable error >> response. Initially the MP and MC state machines treat messages to >> them as errors. After the options processing is completed, one or both >> of them enter a state where they process their corresponding messages. >> >> * Section 6.1: >> >> A general observation: I think it is unclear how the timing of the >> arrival of messages affects this state machine. It seems unnecessarily >> complex to deal with a message arriving at any time, yet it seems >> impossible to avoid that possibility. The best solution I can think of >> is that there should be a message queue associated with the state >> machine. When the outer state machine identifies a message that should >> be processed by this state machine then that message can enter the >> queue. Then this state machine can process messages from that queue at >> convenient times. Those times correspond to the "wait for X" states, >> and the ESTABLISHED state. When in those states, you are really >> waiting for a message, and then must branch on what sort of message it >> is. >> > In general, we adopted the philosophy of keeping it simple and working. > We are quite confident that we avoid hang situations with the proposed > solution. We listed just the events (typically, message sent/received) > triggering state transitions and we do not diagram/consider other events > that should not be possible if implementing correctly the proposed state > machines. I appreciate wanting to keep things simple. Just not *too* simple. :-) I'm trying to understand what "wait for message X" *means*, operationally. What if, while waiting for a particular type of message, some other message type arrives? Is every other type of message ignored while awaiting X? This is made more complicated because we have nested state machines. The MC and MP state machines aren't reading from the channel directly. The outer state machine reads all the messages from the channel, classifies them by type, and then "dispatches" them to the appropriate sub-state machine. When it gets a message it can't wait for the chosen state machine to get into a suitable state to receive the message - it must continue and process any other messages that might arrive. So when there is a message for the MC or MP state machine, either it needs to be queued, or else if the target state machine isn't in the proper state to receive it, then it needs to be dropped. Or, each state machine could have a "slot" for the *latest* incoming message. If a new message arrives and the slot is full, it could be overwritten by the newly arrived message, resulting in the older one being dropped. Thanks, Paul >> What does "retry expired"/"retry not expired" mean, and how does it >> relate to "timeout". (Not just here - also in subsequent sections.) I >> have the impression from past discussions that you intend that there >> be some time limit or limits to be applied to the receipt of certain >> expected messages, and also that there be some limited number of >> retries sending messages when an expected reply has not been received. >> But I don't find even that much detail in the text, and more than that >> is needed to make this be a sufficient specification. (There is a >> *little* bit about retry threshold in 6.2.) Without more detail I >> can't even guess whether that will work adequately. >> > We agree that more text is needed to explain the timeout and retry > mechanism. We plan to add it asap. >> Next, consider >> >> ... CONF+ACK messages referring to out-of-date ADVs should be >> ignored, i.e., they do not trigger any state transition. >> >> Again, ignoring messages seems like a very bad idea. It leads to >> hangs. I think there must be a response to this, indicating that it >> has failed. And perhaps also send a new ADV and hope the consumer gets >> things straightened out after that. >> > The case you present here will be clarified with a sample call flow > which is coherent with the current specification of the state machines. > The rest of your review will be considered in following emails /disussion. > Thank you again, > > Roberta and Simon > >> * Section 6.2: >> >> (Some of the general issues I raised above for 6.1 apply here too.) >> >> An MC in the WAIT FOR ADV state is waiting for an ADV coming from the >> MP. If the ADV arrives ("ADV received"), the MC reaches the >> PROCESSING ADV state. Otherwise, the MC is stuck in the WAIT FOR ADV >> state. >> >> Suppose what arrives is some message other than an ADV. (I guess the >> only thing that could be here is a CONF response.) If something odd >> like that happens then I think it must not be just ignored. But you >> can't send a response to a response. We may need another message to >> report bad things. And/or maybe the channel should be torn down. >> >> ... If >> the NACK retry expires ("retry expired"), the MC moves to the MC >> TERMINATED state. >> >> This is a pretty serious state. I think CLUE is still enabled, but the >> MC is terminated. In that state, what happens to incoming messages? >> (ADVs) If they aren't responded to then bad things will happen. I >> think two things are needed: (1) a NAK must still be sent, with >> indication that this is a fatal error for the MC; (2) in the >> TERMINATED state messages must still be accepted, with error responses >> to requests. Ideally, if the MC goes to the TERMINATED state then we >> want the MP at the other end to also go to that state. >> >> When the SDP information arrives, from the ADV RECEIVED or the ADV >> ACKED state the MC switches to the READY TO CONF state. When the >> CONF request is ready, the MC sends it and moves to the TRYING state. >> If the ADV has not yet been sent, the MC can piggyback the ACK >> message inside the CONF request. >> ... >> When the MC is in the SDP O/A state, the telepresence session >> configuration has been set up at the CLUE application level according >> to the MC's preferences. Both the MP and the MC have agreed on (and >> are aware of) the media streams to be exchanged within the call. In >> this state, the MC waits for the SDP offer coming from the MP. As >> soon as it arrives, the MC replies with an SDP answer. >> >> I wonder if the first of these paragraphs is in the wrong place, or is >> simply old info no longer intended to be here. For instance, I see no >> ADV RECEIVED or ADV ACKED states. And it seems in an odd place in the >> flow of text. >> >> In any case, waiting for SDP may present similar issues to waiting for >> a message. (SDP arrival is far too unsynchronized from the state >> machine to depend on it arriving exactly when you want it.) So it may >> be that the state machine needs a queue for this that can be queried >> from the state that cares. ISTM more consideration is needed of the >> impact of SDP changes on this state machine. >> >> Regarding initiation of an O/A - it certainly can be the case that a >> new O/A is not needed. I see no provision for that possibility. >> >> Perhaps O/A should be handled with a separate state machine - loosely >> coupled (by events) to both MC and MP machines. (So that a newly >> accepted CONF triggers an event to the O/A state machine, causing it >> to analyze the most recent configuration of both MC and MP, and decide >> if a new offer should be sent.) Considering that both ends are likely >> to have both an MC and an MP, it seems like it might be tricky to >> decide who should send a new offer. >> >> * Section 11.4: DNS Registrations >> >> Why do we need any DNS registrations??? >> >> We want a feature tag and an SDP grouping tag, but the signaling draft >> deals with those. >> >> * I didn't yet review the examples. >> >> Thanks, >> Paul >> >> On 10/24/14 9:42 AM, Roberta Presta wrote: >>> Dear all, >>> we have just uploaded the new version of the protocol document to be >>> discussed in the next call. >>> In the following the diff with version 01. >>> Best regards, >>> >>> Roberta >>> >>> o The diff mechanism for the ADV message has been introduced. >>> >>> o READV and READV RESPONSE message have been both removed. >>> >>> o The state machines have been deeply reviewed and changed. >>> >>> o References: references have been updated and splitted into >>> Informative references and Normative references as in framework >>> v17. >>> >>> o Schema: changed in , >>> in >>> >>> o Terminology: many definitions added. Response codes updated. >>> >>> >>> >>> >>> >>> Il 24/10/2014 15:10, internet-drafts@ietf.org ha scritto: >>>> 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 >>>> Authors : Roberta Presta >>>> Simon Pietro Romano >>>> Filename : draft-ietf-clue-protocol-02.txt >>>> Pages : 59 >>>> Date : 2014-10-24 >>>> >>>> Abstract: >>>> The CLUE protocol is an application protocol conceived for the >>>> description and negotiation of a CLUE telepresence session. The >>>> design of the CLUE protocol takes into account the requirements and >>>> the framework defined, respectively, in >>>> [I-D.ietf-clue-framework] and >>>> [I-D.ietf-clue-telepresence-requirements]. The companion document >>>> [I-D.ietf-clue-signaling] delves into CLUE signaling details, as >>>> well >>>> as on the SIP/SDP session establishment phase. CLUE messages flow >>>> upon the CLUE data channel, based on reliable and ordered SCTP over >>>> DTLS transport, as described in [I-D.ietf-clue-datachannel]. >>>> Message >>>> details, together with the behavior of CLUE Participants acting as >>>> Media Providers and/or Media Consumers, are herein discussed. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-clue-protocol-02 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > From nobody Tue Oct 28 09:01:50 2014 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 82F8E1A902E for ; Tue, 28 Oct 2014 09:01:48 -0700 (PDT) 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 aqZpfquZJl5E for ; Tue, 28 Oct 2014 09:01:46 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620E71A901F for ; Tue, 28 Oct 2014 09:01:21 -0700 (PDT) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-07v.sys.comcast.net with comcast id 8g1D1p00554zqzk01g1LZF; Tue, 28 Oct 2014 16:01:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-11v.sys.comcast.net with comcast id 8g1K1p02W3Ge9ey01g1Lpv; Tue, 28 Oct 2014 16:01:20 +0000 Message-ID: <544FBDCD.8020400@alum.mit.edu> Date: Tue, 28 Oct 2014 12:01:17 -0400 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 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=1414512080; bh=59q6fiTzP86cTuKFGKqkaRY8sL3FfqSss17qk8GG3NE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HuOe0GkVvIQuFrSxvPDhAEOEpE/qJYmsSF2vPDX6S67ec03MhNMnekjioznLgU3xw ME+PaHlvbeqy6W8++85fEeOBTT5xCf3b1VIaOHIGRXmwTaQTq4R33jlyAu1E99bQwP lPT+E6+oei2iu9u+Lrp8lRBqxQW6p7W0AeJz3EUEsp1ejWuoKtfSuGQsW0BprbBcQB RMJGiH00DiqtvCNxQ3Iz540cqXzajG5g5ra72AMnouTbyhEylfckLCZtLuqjINWAuJ HIis463Alwb7GCihzn9yeTs5UoHaSOJqNfDzqqHBoQlh1oIX8LpHLyq29m/ox7ME21 opnuQbBF5nWaQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Fmn_5pY1kdWfaLi1LW19g3zFn_Q Subject: [clue] Coupling between Protocol and Signaling wrt O/A 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, 28 Oct 2014 16:01:48 -0000 (Special note to Rob, who wasn't on the call today. This is important for the signaling doc.) On the design team call today we got into a discussion about how the SDP O/A fits into the protocol state machines. Currently the state machines have a *state* for doing O/A. There was concern that this doesn't reflect the way these things occur asynchronously. As I understood the discussion, the desire is that the O/A be addressed by the signaling draft. I think that makes sense, but it leaves open the question of how the two layers coordinate to handle this. My thought is that there is some *state* information from the protocol layer that must be available to the signaling layer. In particular, I think the signaling layer needs the following information to do its job: 1) the most recent configuration sent by the MC layer that has been ACKed without error, and the ADV it references. 2) the most recent configuration received by the MP layer and ACKed without error, and the ADV it references. 3) the most recent ADV received by the MC layer that has been ACKed without error - if different from (1). 4) the most recent ADV sent by the MP layer, if different from (2). 5) an indication when any of the above change. Given all that, the signaling layer can handle O/A as follows: - if an offer is received, the answer SHOULD be generated to be compatible with the above, as best possible. (It may not be possible to include everything desired because of the need to be compatible with the offer.) - when any of the state info (1)-(4) changes, then as soon as not already in the midst of an O/A, a new offer should be generated to be compatible with the above. If it differs from the last SDP send as an offer or answer, then offer should be sent. Note that there is quite a bit of discretion about how the offers and answers are generated. For instance, when an ADV has been sent, a matching offer could immediately be sent, even without waiting for an ACK. Or sending the new offer could be delayed until the ACK is received. In some cases (e.g., when the ADV drops a capture) the offer could be delayed until a new configure is received. In other cases (e.g., when adding an encoding) it can't wait for a configure because the consumer needs the SDP to decide whether to configure it. I don't think there is any need for the signaling layer to inform the protocol layer when O/A occurs. (Except for indications when the SCTP association comes and goes.) It is unfortunate that the "surface" between signaling and protocol is so large, but I don't see how to make it smaller. When things are viewed this way, I think "SDP O/A" should not be a *state* in the MC/MP state machines. Rather, there need to be *actions* on some state transitions, that update the state information shared with the signaling layer. Thanks, Paul From nobody Tue Oct 28 10:02:30 2014 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 1EECE1A8F4D for ; Tue, 28 Oct 2014 10:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, T_REMOTE_IMAGE=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 lUY9Qilk-p_J for ; Tue, 28 Oct 2014 10:02:16 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86F71A8925 for ; Tue, 28 Oct 2014 10:02:15 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id n15so1013220lbi.3 for ; Tue, 28 Oct 2014 10:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tV7bLDdAZCSaPK5/6l6OPJ064gQxqO5aujfan1YsYCc=; b=GeCZOrP9PyBFy3iNh4kPtopKqLu3BA2uwhrQUm6TkFbLunF7FzJ7LrTQZnXqY4v07Q MDSqKcQYZ08Cuww6A1h2kyCiOEENJzPY3OGxbDmZpdJbNGPaMaVv4Fhy5OuwMN7kvDTw RaCPkCqeT2iPoggagkkDx2Q0E1uBXwnRsqgZk7T25QK+m5o1HHhL0Nd0CJtd0MkDd2cS PUOhGUJzW32ovtYMAp85QP5fPGVQq8ms2/Ie0YYtIve2ehGw1DYLAJEYFoNGp8KSwMiQ CwdxPDSFwyhCOf1cWyJbYoYD+CfLI0YUuIC7m1mEFISuiX/XJzzt2tHE5AyEiNZBGjx0 n5sg== MIME-Version: 1.0 X-Received: by 10.112.130.41 with SMTP id ob9mr5329899lbb.74.1414515733617; Tue, 28 Oct 2014 10:02:13 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 10:02:13 -0700 (PDT) Date: Tue, 28 Oct 2014 12:02:13 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b342ba6d4e05205067e9b2f Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZA8bcmanAqmWNoTS2gaLkUn2xXg Subject: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 17:02:24 -0000 --047d7b342ba6d4e05205067e9b2f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable During the design team call today, it was suggested that getting together as a design team at the f2f meeting before the CLUE session could be really helpful. If you look at Roberta's slides from today's meeting, there are several call flows and it would be much easier to discuss concerns, etc with a whiteboard. So, the doodle below is based on a potential slot on Sunday, slots on Monday where there aren't RAI sessions, a slot on Tuesday prior to the social and a slot on Wed. am (another non-RAI slot, I think). Please respond to the poll no later than Monday, November 3rd, 2014. One really important note is that if you come to the meeting, you ought to have read the most recent CLUE protocol document (and signaling really) as we really want to spend focused time and not revisit basic material. If we can't manage this, we will likely schedule another design team meeting using a collaboration tool so folks can make edits to show what they are thinking. Regards, Mary. ---------- Forwarded message ---------- From: Doodle Date: Tue, Oct 28, 2014 at 11:57 AM Subject: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" To: Mary Barnes Hi Mary Barnes, You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at Doodle. The link to your poll is: http://doodle.com/cxz9u66a545x7f7r Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) - Your Doodle Team Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich --047d7b342ba6d4e05205067e9b2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
During the design team call today, it was suggested that g= etting together as a design team at the f2f meeting before the CLUE session= could be really helpful.=C2=A0 If you look at Roberta's slides from to= day's meeting, there are several call flows and it would be much easier= to discuss concerns, etc with a whiteboard.=C2=A0 So, the doodle below is = based on a potential slot on Sunday, slots on Monday where there aren't= RAI sessions, a slot on Tuesday prior to the social and a slot on Wed. am = (another non-RAI slot, I think). =C2=A0 Please respond to the poll no later= than Monday, November 3rd, 2014.=C2=A0

One really impor= tant note is that if you come to the meeting, you ought to have read the mo= st recent CLUE protocol document (and signaling really) as we really want t= o spend focused time and not revisit basic material.

If we can't manage this, we will likely schedule another design team m= eeting using a collaboration tool so folks can make edits to show what they= are thinking.

Regards,
Mary.=C2=A0
<= div>
---------- Forwarded message ----------<= br>From: Doodle <mailer@doodle.com>
Date:= Tue, Oct 28, 2014 at 11:57 AM
Subject: Doodle: Link for poll "CLUE= Design Team - Protocol whiteboarding"
To: Mary Barnes <mary.ietf.barnes@gmail.com>

=09 =09 =09 =09 =09 =09
=09
Hi Mary Barnes,
=C2=A0
=20
=09
You have initiated a poll "CLUE Design Team - Protocol whiteboa= rding" at Doodle. The link to your poll is:

http://doodle.com/cxz9u66a545= x7f7r

Share this link with all those who should cast their votes= . Do not forget to cast your vote, too.
(If you did not initiate this po= ll, somebody must accidentally have used your e-mail address; simply ignore= this e-mail, please.)
=09
=C2=A0
=09
- Your Doodle Team
=09
=09 =09
Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich
=20


--047d7b342ba6d4e05205067e9b2f-- From nobody Tue Oct 28 10:08:39 2014 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 22C591A9070 for ; Tue, 28 Oct 2014 10:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 nUBqK7bq8hnu for ; Tue, 28 Oct 2014 10:08:31 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7919D1A9072 for ; Tue, 28 Oct 2014 10:08:13 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 4C9F84C03DBEA; Tue, 28 Oct 2014 17:08:10 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s9SH8BcN024414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 13:08:12 -0400 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 13:08:11 -0400 From: "Makaraju, Maridi Raju (Raju)" To: Christer Holmberg , Mary Barnes , Christian Groves Thread-Topic: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel Thread-Index: AQHP8qxUKGTTaTnXSUuwrG20MuSG7ZxFucEAgAADP9A= Date: Tue, 28 Oct 2014 17:08:11 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se> <544EE40B.2000308@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D4D0AEB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D0AEB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E5F66E0US70UWXCHMBA02z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/m85ptHhvTs-kcx4yJQWNcIl0J8A Cc: CLUE Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel 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, 28 Oct 2014 17:08:35 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17828E5F66E0US70UWXCHMBA02z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0ZXIsIENocmlzdGlhbiwgTWFyeSwNCg0KVGhhbmtzIGZvciB0aGUgb2ZmZXIgdG8g aGVscC4NCkhvd2V2ZXIsIHBhc3QgZGVsYXlzIHdlcmUgbm90IHJlbGF0ZWQgdG8gYXV0aG9yaW5n IG9mIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0aGUgZG9jdW1lbnQsIGJ1dCByYXRoZXIgZWRp dG9yaWFsIGRlbGF5cy4NCldlIG5vdyByZWN0aWZpZWQgdGhhdCBwcm9ibGVtIGFuZCBmcm9tIG5v dyBvbiBjaGFuZ2VzIHdpbGwgYmUgZG9uZSBpbiBhIHRpbWVseSBtYW5uZXIuDQoNCkFzIGFsd2F5 cywgd2UgYXBwcmVjaWF0ZSB0aGUgc3Ryb25nIHN1cHBvcnQgYW5kIGhlbHAgd2UgYXJlIHJlY2Vp dmVkIChlc3BlY2lhbGx5IGZyb20gUGF1bCBhbmQgQ2hyaXN0ZXIpIGluIHJldmlld2luZyB0aGVz ZSBkb2N1bWVudHMuDQoNClRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzIQ0KUmFqdSBmb3Ig4oCcZHJh ZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcg4oCcIGFuZCDigJxkcmFmdC1lanph ay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWzigJ0gbWVtYmVycy4NCg0KDQoNCkZyb206 IGNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3Rl ciBIb2xtYmVyZw0KU2VudDogVHVlc2RheSwgT2N0b2JlciAyOCwgMjAxNCA3OjUyIEFNDQpUbzog TWFyeSBCYXJuZXM7IENocmlzdGlhbiBHcm92ZXMNCkNjOiBDTFVFDQpTdWJqZWN0OiBSZTogW2Ns dWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgZHJhZnQt ZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsDQoNCkhpLA0KDQpJIHdvdWxkIGJl IHdpbGxpbmcgdG8gaGVscCB0aGUgYXV0aG9yKHMpLCBpZiB0aGV5IG5lZWQgaGVscCA6KQ0KDQpP ZiBjb3Vyc2UsIFNEUCBhdHRyaWJ1dGVzICh3aGljaCB0aGUgZHJhZnQgdGVjaG5pY2FsbHkgaXMg YWxsIGFib3V0KSBjYW4gYWxzbyBiZSBkZWZpbmVkIGVsc2V3aGVyZSwgaWYgTU1VU0lDIHRoaW5r IHRoZXkgYXJlIHRvbyBidXN5Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBjbHVl IFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyeSBCYXJuZXMN ClNlbnQ6IDI4LiBsb2tha3V1dGEgMjAxNCAxNDo0MA0KVG86IENocmlzdGlhbiBHcm92ZXMNCkNj OiBDTFVFDQpTdWJqZWN0OiBSZTogW2NsdWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1j aGFubmVsLXNkcG5lZyBhbmQgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFu bmVsDQoNCk9rYXkuIFNvLCBpZiBmb2xrcyByZWFsbHkgd2FudCB0aGlzIGZvciBDTFVFLCB0aGVu IHdlIE1VU1QgbWFrZSBzdXJlIHRvIHN1cHBvcnQgdGhlIHdvcmsgb24gdGhlIE1NVVNJQyBXRyBt YWlsaW5nIGxpc3QuICAgQXMgSSBzYWlkLCBteSBwcmltYXJ5IGNvbmNlcm4gaXMgdGltaW5nLiBJ ZiB0aGUgY3VycmVudCBhdXRob3IgZG9lc24ndCBoYXZlIHRoZSBjeWNsZXMgKG9yIG5lZWRzIGhl bHApLCB3b3VsZCBhbnlvbmUgaGVyZSBiZSB3aWxsaW5nIHRvIHN0ZXAgaW4gYXMgYSBjby1hdXRo b3IgKGlmIHRoZSBkb2MgaXMgYWdyZWVkIGFzIGEgV0cgZG9jdW1lbnQpIHRvIGVuc3VyZSB0aGUg d29yayBhY3R1YWxseSBnZXRzIGRvbmU/DQoNClRoYW5rcywNCk1hcnkNCg0KT24gTW9uLCBPY3Qg MjcsIDIwMTQgYXQgNzozMiBQTSwgQ2hyaXN0aWFuIEdyb3ZlcyA8Q2hyaXN0aWFuLkdyb3Zlc0Bu dGVjem9uZS5jb208bWFpbHRvOkNocmlzdGlhbi5Hcm92ZXNAbnRlY3pvbmUuY29tPj4gd3JvdGU6 DQpMaWtlIENocmlzdGVyLCBJIGFsc28gdGhpbmsgdGhlIG1lY2hhbmlzbSB3b3VsZCBiZSB1c2Vm dWwuIEFjdHVhbGx5IEkgdGhpbmsgaXRzIGVzc2VudGlhbCB3aGVuIGl0IGNvbWVzIHRvIGVuZHBv aW50cyAoZXNwZWNpYWxseSBnYXRld2F5cykgc3VwcG9ydGluZyBtdWx0aXBsZSBwcm90b2NvbHMg aW4gYSBkYXRhIGNoYW5uZWwuIFNvIEkgaG9wZSB0aGF0IE1NVVNJQyBkb2VzIGFjY2VwdCB0aGUg ZHJhZnQuIElmIGl0IGRvZXMgYmVjb21lIGEgZ2VuZXJhbCBtZWNoYW5pc20gSSB0aGluayB3ZSBo YXZlIHRvIGNvbnNpZGVyIGl0IGluIG91ciBDTFVFIHdvcmsuDQoNCkNocmlzdGlhbg0KDQpPbiAy OC8xMC8yMDE0IDY6MDUgQU0sIE1hcnkgQmFybmVzIHdyb3RlOg0KV2hlbiB3ZSBkaXNjdXNzZWQg dGhpcyBhdCBJRVRGLTkwLCB3ZSBzYWlkIHRoYXQgd2Ugd291bGQgY29uc2lkZXIgaXQgaWYgdGhl IHVwZGF0ZWQgZG9jdW1lbnQgd2FzIHN1Ym1pdHRlZCBubyBsYXRlciB0aGFuIFNlcHRlbWJlciAx c3QgKHBlciB0aGUgbWludXRlcykuICBPZiBjb3Vyc2UsIHRoYXQgZGF0ZSB3YXNuJ3QgbWV0LiAg TXkgc3VnZ2VzdGlvbiBpcyB0aGF0IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyB0byBhZG9wdCB0aGlz IGFzIGFuIE1NVVNJQyBXRyBkZWxpdmVyYWJsZSwgd2UgY291bGQgYWRkIGEgcmVmZXJlbmNlLiBC VVQsIEkgd291bGQgc3RpbGwgYmUgY29uY2VybmVkIGFib3V0IGRlbGF5cyBpbiB0aGF0IHdvcmsg dGhhdCB3b3VsZCByZXN1bHQgaW4gQ0xVRSBkb2N1bWVudHMgc2l0dGluZyBpbiB0aGUgUkZDIGVk aXRvcidzIHF1ZXVlIHdhaXRpbmcgZm9yIHRoYXQgZG9jdW1lbnQuDQoNCkFzIGFuIGluZGl2aWR1 YWwsIGNvbnNpZGVyaW5nIHRoZSBvdmVyYWxsIHBhY2Ugb2YgdGhlIHdvcmsgb24gdGhhdCBkb2N1 bWVudCB0aHVzIGZhciwgSSB3b3VsZCBiZSBxdWl0ZSB3b3JyaWVkIGFib3V0IGFkZGluZyB0aGF0 IGFzIGEgZGVwZW5kZW5jeS4NCg0KUmVnYXJkcywNCk1hcnkuDQoNCk9uIE1vbiwgT2N0IDI3LCAy MDE0IGF0IDE6MjYgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj c3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy aWNzc29uLmNvbT4+PiB3cm90ZToNCg0KICAgIEZZSSwNCg0KICAgIEtlaXRoIGhhcyBzdWJtaXR0 ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgU0RQLWRhdGEtY2hhbm5lbC1uZWcgZHJhZnQuDQoNCiAg ICBQZXJzb25hbGx5IEkgdGhpbmsgdGhlIG1lY2hhbmlzbSB3b3VsZCBiZSB1c2VmdWwsIGJ1dCBJ IHRoaW5rIGl0DQogICAgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgIkNMVUUgb3BpbmlvbiIgYWxz by4gQ3VycmVudGx5IHdlIG9ubHkNCiAgICBoYXZlIGFuIGVkaXRvcidzIG5vdGUgc2F5aW5nIHRo YXQgd2UgbWF5IGNvbnNpZGVyIHRoZSBtZWNoYW5pc20NCiAgICBkZXBlbmRpbmcgb24gaG93IGl0 IHByb2dyZXNzZXMuIEJ1dCwgYXMgd2Uga25vdywgbm90aGluZw0KICAgIHByb2dyZXNzZXMgYnkg aXRzZWxmIGluIElFVEYsIHNvIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHNoYWxsDQogICAg c2F5ICJDTFVFIGhhcyBhbiBpbnRlcmVzdCBpbiB0aGlzIG1lY2hhbmlzbSwgYW5kIHdvdWxkIGxp a2UgaXQgdG8NCiAgICBtb3ZlIGZvcndhcmQiLg0KDQogICAgUmVnYXJkcywNCg0KICAgIENocmlz dGVyDQoNCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogbW11c2lj IFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGll dGYub3JnPg0KICAgIDxtYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Yy1ib3VuY2VzQGlldGYub3JnPj5dIE9uIEJlaGFsZiBPZiBEUkFHRSwgS2VpdGggKEtlaXRoKQ0K ICAgIFNlbnQ6IDI3IE9jdG9iZXIgMjAxNCAxNjozOQ0KICAgIFRvOiBtbXVzaWNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4gPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1t dXNpY0BpZXRmLm9yZz4+DQogICAgU3ViamVjdDogW01NVVNJQ10gZHJhZnQtZWp6YWstbW11c2lj LWRhdGEtY2hhbm5lbC1zZHBuZWcgYW5kDQogICAgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNh Z2UtZGF0YS1jaGFubmVsDQoNCiAgICBCYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBvbiBsaXN0IG92 ZXIgdGhlIGxhc3QgZmV3IGRheXMsIEkgaGF2ZQ0KICAgIHN1Ym1pdHRlZCByZXZpc2VkIHZlcnNp b25zIG9mIHRoZSB0d28gU0RQIG5lZ290aWF0aW9uIG92ZXIgZGF0YQ0KICAgIGNoYW5uZWwgZHJh ZnRzIGFzIGZvbGxvd3M6DQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZWp6YWst bW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMDIudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBLZWl0aCBEcmFnZSBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgIElFVEYg cmVwb3NpdG9yeS4NCg0KICAgIE5hbWU6ICAgICAgICAgICBkcmFmdC1lanphay1tbXVzaWMtZGF0 YS1jaGFubmVsLXNkcG5lZw0KICAgIFJldmlzaW9uOiAgICAgICAwMg0KICAgIFRpdGxlOiAgICAg ICAgICBTRFAtYmFzZWQgIlNDVFAgb3ZlciBEVExTIiBkYXRhIGNoYW5uZWwgbmVnb3RpYXRpb24N CiAgICBEb2N1bWVudCBkYXRlOiAgMjAxNC0xMC0yNw0KICAgIEdyb3VwOiAgICAgICAgICBJbmRp dmlkdWFsIFN1Ym1pc3Npb24NCiAgICBQYWdlczogICAgICAgICAgMjINCiAgICBVUkw6DQogICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZWp6YWstbW11c2ljLWRh dGEtY2hhbm5lbC1zZHBuZWctMDIudHh0DQogICAgU3RhdHVzOg0KICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVn Lw0KICAgIEh0bWxpemVkOg0KICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVq emFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAyDQogICAgRGlmZjoNCiAgICBodHRwOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVs LXNkcG5lZy0wMg0KDQogICAgQWJzdHJhY3Q6DQogICAgICAgVGhlIFJlYWwtVGltZSBDb21tdW5p Y2F0aW9uIGluIFdFQi1icm93c2VycyAoUlRDV2ViKSB3b3JraW5nDQogICAgZ3JvdXAgaXMNCiAg ICAgICBjaGFyZ2VkIHRvIHByb3ZpZGUgcHJvdG9jb2xzIHRvIHN1cHBvcnQgZGlyZWN0IGludGVy YWN0aXZlIHJpY2gNCiAgICAgICBjb21tdW5pY2F0aW9ucyB1c2luZyBhdWRpbywgdmlkZW8sIGFu ZCBkYXRhIGJldHdlZW4gdHdvIHBlZXJzJyB3ZWItDQogICAgICAgYnJvd3NlcnMuICBGb3IgdGhl IHN1cHBvcnQgb2YgZGF0YSBjb21tdW5pY2F0aW9uLCB0aGUgUlRDV2ViDQogICAgd29ya2luZw0K ICAgICAgIGdyb3VwIGhhcyBpbiBwYXJ0aWN1bGFyIGRlZmluZWQgdGhlIGNvbmNlcHQgb2YgYmkt ZGlyZWN0aW9uYWwgZGF0YQ0KICAgICAgIGNoYW5uZWxzIG92ZXIgU0NUUCwgd2hlcmUgZWFjaCBk YXRhIGNoYW5uZWwgbWlnaHQgYmUgdXNlZCB0bw0KICAgICAgIHRyYW5zcG9ydCBvdGhlciBwcm90 b2NvbHMsIGNhbGxlZCBzdWItcHJvdG9jb2xzLiBEYXRhIGNoYW5uZWwgc2V0dXANCiAgICAgICBj YW4gYmUgZG9uZSB1c2luZyBlaXRoZXIgdGhlIGludGVybmFsIGluLWJhbmQgYmFuZCAoYWxzbw0K ICAgIHJlZmVycmVkIHRvDQogICAgICAgYXMgJ2ludGVybmFsJyBmb3IgdGhlIHJlc3Qgb2YgdGhl IGRvY3VtZW50KSBXZWJSVEMgRGF0YSBDaGFubmVsDQogICAgICAgRXN0YWJsaXNobWVudCBQcm90 b2NvbCBvciBzb21lIGV4dGVybmFsIG91dC1vZi1iYW5kIHNpbXBseSByZWZlcnJlZA0KICAgICAg IHRvIGFzICdleHRlcm5hbCBuZWdvdGlhdGlvbicgaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50 IC4gVGhpcw0KICAgICAgIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIFNEUCBvZmZlci9hbnN3 ZXIgZXhjaGFuZ2UgY2FuIGJlIHVzZWQgdG8NCiAgICAgICBhY2hpZXZlIHN1Y2ggYW4gZXh0ZXJu YWwgbmVnb3RpYXRpb24uICBFdmVuIHRob3VnaCBkYXRhDQogICAgY2hhbm5lbHMgYXJlDQogICAg ICAgZGVzaWduZWQgZm9yIFJUQ1dlYiB1c2UgaW5pdGlhbGx5IHRoZXkgbWF5IGJlIHVzZWQgYnkg b3RoZXINCiAgICBwcm90b2NvbHMNCiAgICAgICBsaWtlLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRo ZSBDTFVFIHByb3RvY29sLiAgVGhpcyBkb2N1bWVudCBpcw0KICAgICAgIGludGVuZGVkIHRvIGJl IHVzZWQgd2hlcmV2ZXIgZGF0YSBjaGFubmVscyBhcmUgdXNlZC4NCg0KDQogICAgQSBuZXcgdmVy c2lvbiBvZiBJLUQsDQogICAgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFu bmVsLTAxLnR4dA0KICAgIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VpdGgg RHJhZ2UgYW5kIHBvc3RlZCB0byB0aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQoNCiAgICBOYW1l OiAgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsDQogICAgUmV2aXNp b246ICAgICAgIDAxDQogICAgVGl0bGU6ICAgICAgICAgIE1TUlAgb3ZlciBTQ1RQL0RUTFMgZGF0 YSBjaGFubmVscw0KICAgIERvY3VtZW50IGRhdGU6ICAyMDE0LTEwLTI3DQogICAgR3JvdXA6ICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOiAgICAgICAgICAxMQ0KICAg IFVSTDoNCiAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lanph ay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDEudHh0DQogICAgU3RhdHVzOg0KICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWVqemFrLW1tdXNpYy1tc3Jw LXVzYWdlLWRhdGEtY2hhbm5lbC8NCiAgICBIdG1saXplZDoNCiAgICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDEN CiAgICBEaWZmOg0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWVq emFrLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbC0wMQ0KDQogICAgQWJzdHJhY3Q6DQog ICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRoZSBNZXNzYWdlIFNlc3Npb24gUmVs YXkgUHJvdG9jb2wNCiAgICAoTVNSUCkNCiAgICAgICBjYW4gYmUgaW5zdGFudGlhdGVkIGFzIGEg ZGF0YSBjaGFubmVsIHN1Yi1wcm90b2NvbCwgdXNpbmcgdGhlDQogICAgdGhlIFNEUA0KICAgICAg IG9mZmVyL2Fuc3dlciBleGNoYW5nZS1iYXNlZCBleHRlcm5hbCBuZWdvdGlhdGlvbiBkZWZpbmVk IGluDQogICAgICAgW0ktRC5lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZ10uICBUd28g bmV0d29yayBjb25maWd1cmF0aW9ucw0KICAgICAgIGFyZSBkb2N1bWVudGVkOiBhIFdlYlJUQyBl bmQtdG8tZW5kIGNvbmZpZ3VyYXRpb24gKGNvbm5lY3RpbmcgdHdvDQogICAgICAgTVNSUCBvdmVy IGRhdGEgY2hhbm5lbCBlbmRwb2ludHMpLCBhbmQgYSBnYXRld2F5IGNvbmZpZ3VyYXRpb24NCiAg ICAgICAoY29ubmVjdGluZyBhbiBNU1JQIG92ZXIgZGF0YSBjaGFubmVsIGVuZHBvaW50IHdpdGgg YW4gTVNSUA0KICAgIG92ZXIgVENQDQogICAgICAgZW5kcG9pbnQpLg0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgbW11c2ljIG1haWxpbmcg bGlzdA0KICAgIG1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPiA8bWFpbHRv Om1tdXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBjbHVlIG1haWxpbmcgbGlzdA0K ICAgIGNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+IDxtYWlsdG86Y2x1ZUBpZXRm Lm9yZzxtYWlsdG86Y2x1ZUBpZXRmLm9yZz4+DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jbHVlDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZzxtYWls dG86Y2x1ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2x1ZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K --_000_E1FE4C082A89A246A11D7F32A95A17828E5F66E0US70UWXCHMBA02z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5C YWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIENocmlzdGVy LCBDaHJpc3RpYW4sIE1hcnksDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ VGhhbmtzIGZvciB0aGUgb2ZmZXIgdG8gaGVscC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHBhc3QgZGVsYXlzIHdlcmUgbm90IHJlbGF0ZWQgdG8g YXV0aG9yaW5nIG9mIHRoZSB0ZWNobmljYWwgZGV0YWlscyBvZiB0aGUgZG9jdW1lbnQsIGJ1dCBy YXRoZXIgZWRpdG9yaWFsIGRlbGF5cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2Ugbm93IHJlY3RpZmllZCB0aGF0 IHByb2JsZW0gYW5kIGZyb20gbm93IG9uIGNoYW5nZXMgd2lsbCBiZSBkb25lIGluIGEgdGltZWx5 IG1hbm5lci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGFsd2F5cywgd2UgYXBw cmVjaWF0ZSB0aGUgc3Ryb25nIHN1cHBvcnQgYW5kIGhlbHAgd2UgYXJlIHJlY2VpdmVkIChlc3Bl Y2lhbGx5IGZyb20gUGF1bCBhbmQgQ2hyaXN0ZXIpIGluIHJldmlld2luZyB0aGVzZSBkb2N1bWVu dHMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgYW5kIEJlc3QgUmVnYXJk cyE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+UmFqdSBmb3Ig4oCcZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5l bC1zZHBuZWcg4oCcIGFuZCDigJxkcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNo YW5uZWzigJ0gbWVtYmVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RlciBIb2xtYmVyZzxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBPY3RvYmVyIDI4LCAyMDE0IDc6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnkg QmFybmVzOyBDaHJpc3RpYW4gR3JvdmVzPGJyPg0KPGI+Q2M6PC9iPiBDTFVFPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbY2x1ZV0gRlc6IGRyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwt c2RwbmVnIGFuZCBkcmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHdvdWxkIGJlIHdp bGxpbmcgdG8gaGVscCB0aGUgYXV0aG9yKHMpLCBpZiB0aGV5IG5lZWQgaGVscCA6KTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+T2YgY291cnNlLCBTRFAgYXR0cmlidXRlcyAod2hpY2ggdGhlIGRyYWZ0IHRlY2huaWNhbGx5 IGlzIGFsbCBhYm91dCkgY2FuIGFsc28gYmUgZGVmaW5lZCBlbHNld2hlcmUsIGlmIE1NVVNJQyB0 aGluayB0aGV5IGFyZSB0b28gYnVzeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DaHJp c3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gY2x1ZSBbPGEg aHJlZj0ibWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcnkgQmFybmVzPGJyPg0KPGI+U2Vu dDo8L2I+IDI4LiBsb2tha3V1dGEgMjAxNCAxNDo0MDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0aWFu IEdyb3Zlczxicj4NCjxiPkNjOjwvYj4gQ0xVRTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Ns dWVdIEZXOiBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQgZHJhZnQt ZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T2theS4gU28sIGlmIGZvbGtzIHJlYWxseSB3YW50IHRoaXMgZm9y IENMVUUsIHRoZW4gd2UgTVVTVCBtYWtlIHN1cmUgdG8gc3VwcG9ydCB0aGUgd29yayBvbiB0aGUg TU1VU0lDIFdHIG1haWxpbmcgbGlzdC4gJm5ic3A7IEFzIEkgc2FpZCwgbXkgcHJpbWFyeSBjb25j ZXJuIGlzIHRpbWluZy4gSWYgdGhlIGN1cnJlbnQgYXV0aG9yIGRvZXNuJ3QgaGF2ZSB0aGUgY3lj bGVzIChvciBuZWVkcyBoZWxwKSwgd291bGQgYW55b25lDQogaGVyZSBiZSB3aWxsaW5nIHRvIHN0 ZXAgaW4gYXMgYSBjby1hdXRob3IgKGlmIHRoZSBkb2MgaXMgYWdyZWVkIGFzIGEgV0cgZG9jdW1l bnQpIHRvIGVuc3VyZSB0aGUgd29yayBhY3R1YWxseSBnZXRzIGRvbmU/PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ5PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDI3LCAyMDE0 IGF0IDc6MzIgUE0sIENocmlzdGlhbiBHcm92ZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpDaHJpc3Rp YW4uR3JvdmVzQG50ZWN6b25lLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkNocmlzdGlhbi5Hcm92ZXNA bnRlY3pvbmUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5MaWtlIENocmlzdGVyLCBJIGFsc28gdGhpbmsgdGhlIG1lY2hhbmlzbSB3b3VsZCBi ZSB1c2VmdWwuIEFjdHVhbGx5IEkgdGhpbmsgaXRzIGVzc2VudGlhbCB3aGVuIGl0IGNvbWVzIHRv IGVuZHBvaW50cyAoZXNwZWNpYWxseSBnYXRld2F5cykgc3VwcG9ydGluZyBtdWx0aXBsZSBwcm90 b2NvbHMgaW4gYSBkYXRhIGNoYW5uZWwuIFNvIEkgaG9wZSB0aGF0IE1NVVNJQyBkb2VzIGFjY2Vw dCB0aGUgZHJhZnQuIElmDQogaXQgZG9lcyBiZWNvbWUgYSBnZW5lcmFsIG1lY2hhbmlzbSBJIHRo aW5rIHdlIGhhdmUgdG8gY29uc2lkZXIgaXQgaW4gb3VyIENMVUUgd29yay48YnI+DQo8YnI+DQpD aHJpc3RpYW48YnI+DQo8YnI+DQpPbiAyOC8xMC8yMDE0IDY6MDUgQU0sIE1hcnkgQmFybmVzIHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiB3ZSBkaXNjdXNz ZWQgdGhpcyBhdCBJRVRGLTkwLCB3ZSBzYWlkIHRoYXQgd2Ugd291bGQgY29uc2lkZXIgaXQgaWYg dGhlIHVwZGF0ZWQgZG9jdW1lbnQgd2FzIHN1Ym1pdHRlZCBubyBsYXRlciB0aGFuIFNlcHRlbWJl ciAxc3QgKHBlciB0aGUgbWludXRlcykuJm5ic3A7IE9mIGNvdXJzZSwgdGhhdCBkYXRlIHdhc24n dCBtZXQuJm5ic3A7IE15IHN1Z2dlc3Rpb24gaXMgdGhhdCBpZiB0aGVyZSBpcyBjb25zZW5zdXMg dG8NCiBhZG9wdCB0aGlzIGFzIGFuIE1NVVNJQyBXRyBkZWxpdmVyYWJsZSwgd2UgY291bGQgYWRk IGEgcmVmZXJlbmNlLiBCVVQsIEkgd291bGQgc3RpbGwgYmUgY29uY2VybmVkIGFib3V0IGRlbGF5 cyBpbiB0aGF0IHdvcmsgdGhhdCB3b3VsZCByZXN1bHQgaW4gQ0xVRSBkb2N1bWVudHMgc2l0dGlu ZyBpbiB0aGUgUkZDIGVkaXRvcidzIHF1ZXVlIHdhaXRpbmcgZm9yIHRoYXQgZG9jdW1lbnQuPGJy Pg0KPGJyPg0KQXMgYW4gaW5kaXZpZHVhbCwgY29uc2lkZXJpbmcgdGhlIG92ZXJhbGwgcGFjZSBv ZiB0aGUgd29yayBvbiB0aGF0IGRvY3VtZW50IHRodXMgZmFyLCBJIHdvdWxkIGJlIHF1aXRlIHdv cnJpZWQgYWJvdXQgYWRkaW5nIHRoYXQgYXMgYSBkZXBlbmRlbmN5Ljxicj4NCjxicj4NClJlZ2Fy ZHMsPGJyPg0KTWFyeS48YnI+DQo8YnI+DQpPbiBNb24sIE9jdCAyNywgMjAxNCBhdCAxOjI2IFBN LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PC9hPiZndDsmZ3Q7DQogd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBGWUksPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBLZWl0aCBoYXMgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2Yg dGhlIFNEUC1kYXRhLWNoYW5uZWwtbmVnIGRyYWZ0Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg UGVyc29uYWxseSBJIHRoaW5rIHRoZSBtZWNoYW5pc20gd291bGQgYmUgdXNlZnVsLCBidXQgSSB0 aGluayBpdDxicj4NCiZuYnNwOyAmbmJzcDsgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgJnF1b3Q7 Q0xVRSBvcGluaW9uJnF1b3Q7IGFsc28uIEN1cnJlbnRseSB3ZSBvbmx5PGJyPg0KJm5ic3A7ICZu YnNwOyBoYXZlIGFuIGVkaXRvcidzIG5vdGUgc2F5aW5nIHRoYXQgd2UgbWF5IGNvbnNpZGVyIHRo ZSBtZWNoYW5pc208YnI+DQombmJzcDsgJm5ic3A7IGRlcGVuZGluZyBvbiBob3cgaXQgcHJvZ3Jl c3Nlcy4gQnV0LCBhcyB3ZSBrbm93LCBub3RoaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyBwcm9ncmVz c2VzIGJ5IGl0c2VsZiBpbiBJRVRGLCBzbyB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBzaGFs bDxicj4NCiZuYnNwOyAmbmJzcDsgc2F5ICZxdW90O0NMVUUgaGFzIGFuIGludGVyZXN0IGluIHRo aXMgbWVjaGFuaXNtLCBhbmQgd291bGQgbGlrZSBpdCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgbW92 ZSBmb3J3YXJkJnF1b3Q7Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUmVnYXJkcyw8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IENocmlzdGVyPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZuYnNwOyAmbmJzcDsgRnJvbTogbW11 c2ljIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KJm5ic3A7ICZuYnNw OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDtdIE9uIEJlaGFsZiBP ZiBEUkFHRSwgS2VpdGggKEtlaXRoKTxicj4NCiZuYnNwOyAmbmJzcDsgU2VudDogMjcgT2N0b2Jl ciAyMDE0IDE2OjM5PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgVG86IDxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOm1tdXNpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiBbTU1VU0lDXSBkcmFmdC1lanphay1t bXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IGRyYWZ0LWVq emFrLW1tdXNpYy1tc3JwLXVzYWdlLWRhdGEtY2hhbm5lbDxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDsgQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gb24gbGlzdCBvdmVyIHRoZSBsYXN0IGZldyBkYXlz LCBJIGhhdmU8YnI+DQombmJzcDsgJm5ic3A7IHN1Ym1pdHRlZCByZXZpc2VkIHZlcnNpb25zIG9m IHRoZSB0d28gU0RQIG5lZ290aWF0aW9uIG92ZXIgZGF0YTxicj4NCiZuYnNwOyAmbmJzcDsgY2hh bm5lbCBkcmFmdHMgYXMgZm9sbG93czo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMi50 eHQ8YnI+DQombmJzcDsgJm5ic3A7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg S2VpdGggRHJhZ2UgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQombmJzcDsgJm5ic3A7IElFVEYgcmVw b3NpdG9yeS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNk cG5lZzxicj4NCiZuYnNwOyAmbmJzcDsgUmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7MDI8YnI+DQombmJzcDsgJm5ic3A7IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgU0RQLWJhc2VkICZxdW90O1NDVFAgb3ZlciBEVExTJnF1b3Q7IGRhdGEgY2hhbm5l bCBuZWdvdGlhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgRG9jdW1lbnQgZGF0ZTombmJzcDsgMjAx NC0xMC0yNzxicj4NCiZuYnNwOyAmbmJzcDsgR3JvdXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQombmJzcDsgJm5ic3A7IFBhZ2Vz OiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgMjI8YnI+DQombmJzcDsgJm5ic3A7 IFVSTDo8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAyLnR4 dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMDIudHh0PC9hPjxicj4NCiZu YnNwOyAmbmJzcDsgU3RhdHVzOjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1z ZHBuZWcvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy88L2E+PGJyPg0KJm5ic3A7 ICZuYnNwOyBIdG1saXplZDo8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWVqemFrLW1tdXNpYy1kYXRhLWNoYW5uZWwtc2RwbmVnLTAy IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lanph ay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMjwvYT48YnI+DQombmJzcDsgJm5ic3A7IERp ZmY6PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZy0wMiIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZWp6YWst bW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWctMDI8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyBBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgUmVhbC1UaW1l IENvbW11bmljYXRpb24gaW4gV0VCLWJyb3dzZXJzIChSVENXZWIpIHdvcmtpbmc8YnI+DQombmJz cDsgJm5ic3A7IGdyb3VwIGlzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhcmdl ZCB0byBwcm92aWRlIHByb3RvY29scyB0byBzdXBwb3J0IGRpcmVjdCBpbnRlcmFjdGl2ZSByaWNo PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29tbXVuaWNhdGlvbnMgdXNpbmcgYXVk aW8sIHZpZGVvLCBhbmQgZGF0YSBiZXR3ZWVuIHR3byBwZWVycycgd2ViLTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2Jyb3dzZXJzLiZuYnNwOyBGb3IgdGhlIHN1cHBvcnQgb2YgZGF0 YSBjb21tdW5pY2F0aW9uLCB0aGUgUlRDV2ViPGJyPg0KJm5ic3A7ICZuYnNwOyB3b3JraW5nPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Z3JvdXAgaGFzIGluIHBhcnRpY3VsYXIgZGVm aW5lZCB0aGUgY29uY2VwdCBvZiBiaS1kaXJlY3Rpb25hbCBkYXRhPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y2hhbm5lbHMgb3ZlciBTQ1RQLCB3aGVyZSBlYWNoIGRhdGEgY2hhbm5l bCBtaWdodCBiZSB1c2VkIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHJhbnNw b3J0IG90aGVyIHByb3RvY29scywgY2FsbGVkIHN1Yi1wcm90b2NvbHMuIERhdGEgY2hhbm5lbCBz ZXR1cDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NhbiBiZSBkb25lIHVzaW5nIGVp dGhlciB0aGUgaW50ZXJuYWwgaW4tYmFuZCBiYW5kIChhbHNvPGJyPg0KJm5ic3A7ICZuYnNwOyBy ZWZlcnJlZCB0bzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FzICdpbnRlcm5hbCcg Zm9yIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCkgV2ViUlRDIERhdGEgQ2hhbm5lbDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0VzdGFibGlzaG1lbnQgUHJvdG9jb2wgb3Igc29tZSBl eHRlcm5hbCBvdXQtb2YtYmFuZCBzaW1wbHkgcmVmZXJyZWQ8YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt0byBhcyAnZXh0ZXJuYWwgbmVnb3RpYXRpb24nIGluIHRoZSByZXN0IG9mIHRo ZSBkb2N1bWVudCAuIFRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb2N1bWVu dCBzcGVjaWZpZXMgaG93IHRoZSBTRFAgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGNhbiBiZSB1c2Vk IHRvPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWNoaWV2ZSBzdWNoIGFuIGV4dGVy bmFsIG5lZ290aWF0aW9uLiZuYnNwOyBFdmVuIHRob3VnaCBkYXRhPGJyPg0KJm5ic3A7ICZuYnNw OyBjaGFubmVscyBhcmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNpZ25lZCBm b3IgUlRDV2ViIHVzZSBpbml0aWFsbHkgdGhleSBtYXkgYmUgdXNlZCBieSBvdGhlcjxicj4NCiZu YnNwOyAmbmJzcDsgcHJvdG9jb2xzPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGlr ZSwgYnV0IG5vdCBsaW1pdGVkIHRvLCB0aGUgQ0xVRSBwcm90b2NvbC4mbmJzcDsgVGhpcyBkb2N1 bWVudCBpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ludGVuZGVkIHRvIGJlIHVz ZWQgd2hlcmV2ZXIgZGF0YSBjaGFubmVscyBhcmUgdXNlZC48YnI+DQo8YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7IEEgbmV3IHZlcnNpb24gb2YgSS1ELDxicj4NCiZuYnNwOyAmbmJzcDsgZHJhZnQt ZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLTAxLnR4dDxicj4NCiZuYnNwOyAm bmJzcDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZWl0aCBEcmFnZSBhbmQg cG9zdGVkIHRvIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgTmFtZTombmJzcDsgZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNh Z2UtZGF0YS1jaGFubmVsPGJyPg0KJm5ic3A7ICZuYnNwOyBSZXZpc2lvbjombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDswMTxicj4NCiZuYnNwOyAmbmJzcDsgVGl0bGU6Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBNU1JQIG92ZXIgU0NUUC9EVExTIGRhdGEgY2hhbm5lbHM8YnI+ DQombmJzcDsgJm5ic3A7IERvY3VtZW50IGRhdGU6Jm5ic3A7IDIwMTQtMTAtMjc8YnI+DQombmJz cDsgJm5ic3A7IEdyb3VwOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uPGJyPg0KJm5ic3A7ICZuYnNwOyBQYWdlczombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDExPGJyPg0KJm5ic3A7ICZuYnNwOyBVUkw6PGJyPg0KJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDEudHh0IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1lanphay1t bXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDEudHh0PC9hPjxicj4NCiZuYnNwOyAmbmJz cDsgU3RhdHVzOjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVs LyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVsLzwvYT48YnI+DQombmJzcDsg Jm5ic3A7IEh0bWxpemVkOjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVs LTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1l anphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDE8L2E+PGJyPg0KJm5ic3A7ICZu YnNwOyBEaWZmOjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtZWp6YWstbW11c2ljLW1zcnAtdXNhZ2UtZGF0YS1jaGFubmVs LTAxIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1lanphay1tbXVzaWMtbXNycC11c2FnZS1kYXRhLWNoYW5uZWwtMDE8L2E+PGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIE1lc3NhZ2UgU2Vzc2lvbiBSZWxheSBQ cm90b2NvbDxicj4NCiZuYnNwOyAmbmJzcDsgKE1TUlApPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y2FuIGJlIGluc3RhbnRpYXRlZCBhcyBhIGRhdGEgY2hhbm5lbCBzdWItcHJvdG9j b2wsIHVzaW5nIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgdGhlIFNEUDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO29mZmVyL2Fuc3dlciBleGNoYW5nZS1iYXNlZCBleHRlcm5hbCBuZWdv dGlhdGlvbiBkZWZpbmVkIGluPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0ktRC5l anphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZ10uJm5ic3A7IFR3byBuZXR3b3JrIGNvbmZp Z3VyYXRpb25zPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXJlIGRvY3VtZW50ZWQ6 IGEgV2ViUlRDIGVuZC10by1lbmQgY29uZmlndXJhdGlvbiAoY29ubmVjdGluZyB0d288YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNU1JQIG92ZXIgZGF0YSBjaGFubmVsIGVuZHBvaW50 cyksIGFuZCBhIGdhdGV3YXkgY29uZmlndXJhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyhjb25uZWN0aW5nIGFuIE1TUlAgb3ZlciBkYXRhIGNoYW5uZWwgZW5kcG9pbnQgd2l0 aCBhbiBNU1JQPGJyPg0KJm5ic3A7ICZuYnNwOyBvdmVyIFRDUDxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2VuZHBvaW50KS48YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBtbXVz aWMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzptbXVzaWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tbXVzaWNAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5i c3A7ICZuYnNwOyBjbHVlIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i bWFpbHRvOmNsdWVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jbHVlQGlldGYub3JnPC9hPiAm bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjbHVlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y2x1ZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+PGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpjbHVlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjbHVlQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2x1ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY2x1ZSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Y2x1ZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmNsdWVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jbHVlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jbHVlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E1FE4C082A89A246A11D7F32A95A17828E5F66E0US70UWXCHMBA02z_-- From nobody Tue Oct 28 10:17:24 2014 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 785311A9095 for ; Tue, 28 Oct 2014 10:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 A2pFYfKytqg5 for ; Tue, 28 Oct 2014 10:17:19 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D161A907F for ; Tue, 28 Oct 2014 10:17:18 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id n3so9446562wiv.3 for ; Tue, 28 Oct 2014 10:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=JSTdZ1uLh/lslGu4nzQJM/TJGeV8ustnN8ls2AObg9g=; b=YSFcyb15WcUrj9TMa/WDytlksgw9Oz08TlDkEnhT9ZpUIc5lv4CunPvprVMh0uH/rV +PPcvCpAE2HfbCiR++6jyysVBNXhTEVc9o0ZwysYortEG8LQTk0MtdhTRs5snLtiBwX+ PP6NVi7gJ1EaLrThyKVNlToBY41lk9qnC7ZkqiJfre+Bby3m/mguxW1lMbow+KQRUlwJ XNolnPbGbpJ3W6A9uMpDvk201Iuxz3EmwJT9mgXFD0LaV43+w8W8du+r8vRd7NnVGi4B nq1CN3ifUTS1cF7FMMIpizQT2XyN4cKC3p9KmvfofFAxJxSaeRn0+ZQsvoWT8gzJI7+E HbHg== X-Received: by 10.180.74.237 with SMTP id x13mr6632876wiv.6.1414516637186; Tue, 28 Oct 2014 10:17:17 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id gw6sm2878824wib.8.2014.10.28.10.17.14 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Oct 2014 10:17:16 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 28 Oct 2014 19:17:11 +0200 Message-ID: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08B3_01CFF2E3.C87989A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJjPgeB5AVqzK2St3ZvC+hMtOPZepsfKXZQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NpsUblQSJMMT2pHRZgNMucFqPWU Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 17:17:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08B3_01CFF2E3.C87989A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mary, The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText. I am = not sure that this is what you meant =20 Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 28 October, 2014 7:02 PM To: CLUE Subject: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol = whiteboarding" =20 During the design team call today, it was suggested that getting = together as a design team at the f2f meeting before the CLUE session = could be really helpful. If you look at Roberta's slides from today's = meeting, there are several call flows and it would be much easier to = discuss concerns, etc with a whiteboard. So, the doodle below is based = on a potential slot on Sunday, slots on Monday where there aren't RAI = sessions, a slot on Tuesday prior to the social and a slot on Wed. am = (another non-RAI slot, I think). Please respond to the poll no later = than Monday, November 3rd, 2014.=20 =20 One really important note is that if you come to the meeting, you ought = to have read the most recent CLUE protocol document (and signaling = really) as we really want to spend focused time and not revisit basic = material. =20 If we can't manage this, we will likely schedule another design team = meeting using a collaboration tool so folks can make edits to show what = they are thinking. =20 Regards, Mary.=20 =20 ---------- Forwarded message ---------- From: Doodle Date: Tue, Oct 28, 2014 at 11:57 AM Subject: Doodle: Link for poll "CLUE Design Team - Protocol = whiteboarding" To: Mary Barnes =09 =09 =09 =20 =09 =09 =09 Hi Mary Barnes,=20 =09 =20 =09 You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at = Doodle. The link to your poll is: http://doodle.com/cxz9u66a545x7f7r Share this link with all those who should cast their votes. Do not = forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used = your e-mail address; simply ignore this e-mail, please.)=20 =20 =20 =20 - Your Doodle Team=20 =09 Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich=20 =09 =20 ------=_NextPart_000_08B3_01CFF2E3.C87989A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mary,

The slot on Tuesday in the doodle is 3:20-4:20PM which is = AVText.=C2=A0 I am not sure that this is what you = meant

 

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 28 October, 2014 7:02 PM
To: = CLUE
Subject: [clue] Fwd: Doodle: Link for poll "CLUE = Design Team - Protocol = whiteboarding"

 

During = the design team call today, it was suggested that getting together as a = design team at the f2f meeting before the CLUE session could be really = helpful.  If you look at Roberta's slides from today's meeting, = there are several call flows and it would be much easier to discuss = concerns, etc with a whiteboard.  So, the doodle below is based on = a potential slot on Sunday, slots on Monday where there aren't RAI = sessions, a slot on Tuesday prior to the social and a slot on Wed. am = (another non-RAI slot, I think).   Please respond to the poll no = later than Monday, November 3rd, 2014. 

 

One really important note is that if you come to the = meeting, you ought to have read the most recent CLUE protocol document = (and signaling really) as we really want to spend focused time and not = revisit basic material.

 

If we can't manage this, we will likely schedule = another design team meeting using a collaboration tool so folks can make = edits to show what they are thinking.

 

Regards,

Mary. 

 

---------- Forwarded message = ----------
From: Doodle <mailer@doodle.com>
Date: = Tue, Oct 28, 2014 at 11:57 AM
Subject: Doodle: Link for poll = "CLUE Design Team - Protocol whiteboarding"
To: Mary Barnes = <mary.ietf.barnes@gmail.com= >

Hi Mary Barnes, =

  =

You have = initiated a poll "CLUE Design Team - Protocol whiteboarding" = at Doodle. The link to your poll is:

http://doodle.com/cxz9u66a545x7f7r

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

 

  =

 

- Your Doodle = Team

= Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich =

 

------=_NextPart_000_08B3_01CFF2E3.C87989A0-- From nobody Tue Oct 28 10:21:43 2014 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 4FE8E1A90BD for ; Tue, 28 Oct 2014 10:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 lXEMqrrlru6c for ; Tue, 28 Oct 2014 10:21:40 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E5C1A9096 for ; Tue, 28 Oct 2014 10:21:39 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id z11so1044340lbi.30 for ; Tue, 28 Oct 2014 10:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1SaqZ/5qzM49m4YGJbEcvj8ShEs/uk7ErZqzytkzvMw=; b=Tap7ayeYFHfnDr2kS3kyhdboe2AIf8eGbSNxo2lxvi+H+lzC1+L8KYcSi6wZmo2MP+ e022UeTRHhlKsDkIucxQ4Uwd3SH+jZVLRljZizyT8eHdZ+yU676EJXb6kyS2opaGrM3C /ldK2lzqZBd7Q9ejcBCoqvnOI5fZW8adMBEzo8w4mRavkrnl/gXQLQ0LMt4eTZExgcp8 k2NrinGtUUxUq64wM93OstyGCEc8r7p2mMddGoZ2bHPa4c9Cm4AAeJ/3oKTNCh7HMw2X 72c6h4bvMS65qL6NbLVu+ff3hS7yu+IKYviIEjhgm9eti1Ccw+WWrA4G6+bjz71DT3cq Gh5A== MIME-Version: 1.0 X-Received: by 10.112.139.196 with SMTP id ra4mr2880931lbb.95.1414516897803; Tue, 28 Oct 2014 10:21:37 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 10:21:37 -0700 (PDT) In-Reply-To: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> References: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> Date: Tue, 28 Oct 2014 12:21:37 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=001a11c33fcc38f17f05067ee1c8 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4EWlYQ9UtxTH9CbroJPzLsK_h0s Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 17:21:42 -0000 --001a11c33fcc38f17f05067ee1c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No, I meant right after AVTEXT and just before the social. I typed in 1520 (making the usual mistake that this is 5:20 PM and of course, the poll converted to 3:20 pm). I updated the poll. On Tue, Oct 28, 2014 at 12:17 PM, Roni Even wrote: > Hi Mary, > > The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText. I am > not sure that this is what you meant > > > > Roni > > > > *From:* clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > *Sent:* 28 October, 2014 7:02 PM > *To:* CLUE > *Subject:* [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol > whiteboarding" > > > > During the design team call today, it was suggested that getting together > as a design team at the f2f meeting before the CLUE session could be real= ly > helpful. If you look at Roberta's slides from today's meeting, there are > several call flows and it would be much easier to discuss concerns, etc > with a whiteboard. So, the doodle below is based on a potential slot on > Sunday, slots on Monday where there aren't RAI sessions, a slot on Tuesda= y > prior to the social and a slot on Wed. am (another non-RAI slot, I think)= . > Please respond to the poll no later than Monday, November 3rd, 2014. > > > > One really important note is that if you come to the meeting, you ought t= o > have read the most recent CLUE protocol document (and signaling really) a= s > we really want to spend focused time and not revisit basic material. > > > > If we can't manage this, we will likely schedule another design team > meeting using a collaboration tool so folks can make edits to show what > they are thinking. > > > > Regards, > > Mary. > > > > ---------- Forwarded message ---------- > From: *Doodle* > Date: Tue, Oct 28, 2014 at 11:57 AM > Subject: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding= " > To: Mary Barnes > > > > Hi Mary Barnes, > > > > You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at > Doodle. The link to your poll is: > > http://doodle.com/cxz9u66a545x7f7r > > Share this link with all those who should cast their votes. Do not forget > to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > > > > > > > - Your Doodle Team > > Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich > > > --001a11c33fcc38f17f05067ee1c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No, I meant right after AVTEXT and just before the social.= I typed in 1520 (making the usual mistake that this is 5:20 PM and of cour= se, the poll converted to 3:20 pm).=C2=A0 I updated the poll.


On Tue, Oc= t 28, 2014 at 12:17 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Mary,

The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText.= =C2=A0 I am not sure that this is what you meant

=C2=A0=

Roni

=C2=A0<= /u>

Fr= om: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary= Barnes
Sent: 28 October, 2014 7:02 PM
To: CLUE
S= ubject: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Prot= ocol whiteboarding"

=C2=A0

During the design team call today, it was suggested that getting t= ogether as a design team at the f2f meeting before the CLUE session could b= e really helpful.=C2=A0 If you look at Roberta's slides from today'= s meeting, there are several call flows and it would be much easier to disc= uss concerns, etc with a whiteboard.=C2=A0 So, the doodle below is based on= a potential slot on Sunday, slots on Monday where there aren't RAI ses= sions, a slot on Tuesday prior to the social and a slot on Wed. am (another= non-RAI slot, I think). =C2=A0 Please respond to the poll no later than Mo= nday, November 3rd, 2014.=C2=A0

=C2=A0

One really impo= rtant note is that if you come to the meeting, you ought to have read the m= ost recent CLUE protocol document (and signaling really) as we really want = to spend focused time and not revisit basic material.

=C2=A0

If we can't manage this, we will likely schedule another design = team meeting using a collaboration tool so folks can make edits to show wha= t they are thinking.

= =C2=A0

Regards,

Mary.=C2=A0

<= p class=3D"MsoNormal">=C2=A0

---------- Forwarded message ----------
Fr= om: Doodle <mailer@doodle.com>
Date: Tue, Oct 28, 2014 at 11:57 AM
Subje= ct: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding&q= uot;
To: Mary Barnes <mary.ietf.barnes@gmail.com>

=
=

Hi Mary = Barnes,

=C2=A0

You have initiated a poll "CLUE Design T= eam - Protocol whiteboarding" at Doodle. The link to your poll is:
=
http:/= /doodle.com/cxz9u66a545x7f7r

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

=C2=A0

=C2=A0

=C2=A0

<= td valign=3D"top" style=3D"padding:0in 0in 0in 0in">

- Your Doodle Team

Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich <= /u>

=C2=A0


--001a11c33fcc38f17f05067ee1c8-- From nobody Tue Oct 28 10:30:26 2014 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 3EA161A90F5 for ; Tue, 28 Oct 2014 10:30:23 -0700 (PDT) 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 VXfhQwiWrKCv for ; Tue, 28 Oct 2014 10:30:22 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629941A9048 for ; Tue, 28 Oct 2014 10:29:48 -0700 (PDT) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-09v.sys.comcast.net with comcast id 8hVU1p0035BUCh401hVn6B; Tue, 28 Oct 2014 17:29:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id 8hVn1p0023Ge9ey01hVnxw; Tue, 28 Oct 2014 17:29:47 +0000 Message-ID: <544FD28A.4040304@alum.mit.edu> Date: Tue, 28 Oct 2014 13:29:46 -0400 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414517387; bh=97ob4aVDkATO9ijIkW6iyQ4rxfdkd59DkLuNy4B2Dlk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OW2ArkXRVMOJbdwXQblxjCM9MT+hZ0M74Im3xdr5X71CTnsUD1Snr1sLPIIywuysz CKxcgIjeESVp0y/2sBqjbafK5cTVEaofbw6tLqubAaVf16R6sqXQIXwPhc9aAxnEiI 0/fsd96xTtfv8+BSCHgXQsZUeIlOzZMBtLKLjdOvfX4/L95hmAhfslDLm4N/Be2v70 udDtgXJK8jFYzXwibkLF9Wlaqc+cjGLs8PaGsD966LvuS2sHr32MFHAgG9lpSZEiZQ gE5kBX27ktqiid5ljRdG6Nw6vsB+RKwkneo6SByKyXg7kUqRrbDbgfuedAnREjCA4s aEYCCob2txNcw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VH-MBnz5QYATSsgFT8_IxJfTLbw Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 17:30:23 -0000 On 10/28/14 1:02 PM, Mary Barnes wrote: > During the design team call today, it was suggested that getting > together as a design team at the f2f meeting before the CLUE session > could be really helpful. If you look at Roberta's slides from today's > meeting, there are several call flows and it would be much easier to > discuss concerns, etc with a whiteboard. So, the doodle below is based > on a potential slot on Sunday, slots on Monday where there aren't RAI > sessions, a slot on Tuesday prior to the social and a slot on Wed. am > (another non-RAI slot, I think). Please respond to the poll no later > than Monday, November 3rd, 2014. > > One really important note is that if you come to the meeting, you ought > to have read the most recent CLUE protocol document (and signaling > really) as we really want to spend focused time and not revisit basic > material. It isn't sufficient to have looked at the diffs casually, or even looked casually at the state machines. What we need are people who have worked through the state machines in detail, state by state and transition by transition. You should have considered what problems could arise when implementing this. And we really need multiple people to have gone through this level of review!!! Thanks, Paul From nobody Tue Oct 28 10:38:14 2014 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 2CA851A901E for ; Tue, 28 Oct 2014 10:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 CLu3Y5akjhz7 for ; Tue, 28 Oct 2014 10:38:05 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AF3F1A90AA for ; Tue, 28 Oct 2014 10:35:51 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id x13so15924wgg.33 for ; Tue, 28 Oct 2014 10:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=kGFbEvoAjWT5/bSmHxBWLNWoiWG7OGTDcY4io/IUCHI=; b=fzvqa4rYHdOYsMbbdNQsW4XgkXay/z9likcGuvkEBEl/JmiaaucWJZfPD7YF/b3HAo DE9AkgkgFKhZ09lzcxRf1M6c9iuXmFH8gJqzoPBGIvU9t4pcb8hvk9+pgTVff7xUqvX+ rjwPgGQBJkEKBFuXimtbs3/bOeY614vMZCtY1r9Vz2VCthVp30ssE7nWAredMWOTGDBP Xnoq5ujqNm1wUjBUUEwwamaUMDtouM62u3Xk3kNBLMzL2+hivhfeCY2Z424SMLit9IaP OBYCI3OH5ba8rftOtS33OCJUOTChYUEgyixLD1IeMUr3Yn+1phdf0fGbctaTUjQaGTdH l5zA== X-Received: by 10.194.206.36 with SMTP id ll4mr6140219wjc.21.1414517747584; Tue, 28 Oct 2014 10:35:47 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id n4sm2200294wjb.40.2014.10.28.10.35.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Oct 2014 10:35:46 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> In-Reply-To: Date: Tue, 28 Oct 2014 19:35:36 +0200 Message-ID: <08c001cff2d5$9ac3e900$d04bbb00$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C1_01CFF2E6.5E4F02F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJjPgeB5AVqzK2St3ZvC+hMtOPZegH7btC9AUkesJKbBQpW4A== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-HnYuDgd7XEyjqBoJJuOME6mWKY Cc: 'CLUE' Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 17:38:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_08C1_01CFF2E6.5E4F02F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mary, On Tuesday we may start earlier if we say after AVText and it finish = earlier.=20 =20 Roni =20 From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: 28 October, 2014 7:22 PM To: Roni Even Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - = Protocol whiteboarding" =20 No, I meant right after AVTEXT and just before the social. I typed in = 1520 (making the usual mistake that this is 5:20 PM and of course, the = poll converted to 3:20 pm). I updated the poll. =20 =20 On Tue, Oct 28, 2014 at 12:17 PM, Roni Even = wrote: Hi Mary, The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText. I am = not sure that this is what you meant =20 Roni =20 From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 28 October, 2014 7:02 PM To: CLUE Subject: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol = whiteboarding" =20 During the design team call today, it was suggested that getting = together as a design team at the f2f meeting before the CLUE session = could be really helpful. If you look at Roberta's slides from today's = meeting, there are several call flows and it would be much easier to = discuss concerns, etc with a whiteboard. So, the doodle below is based = on a potential slot on Sunday, slots on Monday where there aren't RAI = sessions, a slot on Tuesday prior to the social and a slot on Wed. am = (another non-RAI slot, I think). Please respond to the poll no later = than Monday, November 3rd, 2014.=20 =20 One really important note is that if you come to the meeting, you ought = to have read the most recent CLUE protocol document (and signaling = really) as we really want to spend focused time and not revisit basic = material. =20 If we can't manage this, we will likely schedule another design team = meeting using a collaboration tool so folks can make edits to show what = they are thinking. =20 Regards, Mary.=20 =20 ---------- Forwarded message ---------- From: Doodle Date: Tue, Oct 28, 2014 at 11:57 AM Subject: Doodle: Link for poll "CLUE Design Team - Protocol = whiteboarding" To: Mary Barnes =09 =09 =09 =20 =09 =09 =09 Hi Mary Barnes,=20 =09 =20 =09 You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at = Doodle. The link to your poll is: http://doodle.com/cxz9u66a545x7f7r Share this link with all those who should cast their votes. Do not = forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used = your e-mail address; simply ignore this e-mail, please.)=20 =20 =20 =20 - Your Doodle Team=20 =09 Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich=20 =09 =20 =20 ------=_NextPart_000_08C1_01CFF2E6.5E4F02F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Mary,

On Tuesday we may start earlier if we say after AVText and it finish = earlier.

 

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 28 = October, 2014 7:22 PM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE = Design Team - Protocol = whiteboarding"

 

No, I = meant right after AVTEXT and just before the social. I typed in 1520 = (making the usual mistake that this is 5:20 PM and of course, the poll = converted to 3:20 pm).  I updated the poll.

 

 

On Tue, = Oct 28, 2014 at 12:17 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Mary,

The slot on Tuesday in the doodle is 3:20-4:20PM which is = AVText.  I am not sure that this is what you = meant

 

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 28 October, 2014 7:02 PM
To: = CLUE
Subject: [clue] Fwd: Doodle: Link for poll "CLUE = Design Team - Protocol = whiteboarding"

 <= /o:p>

During the = design team call today, it was suggested that getting together as a = design team at the f2f meeting before the CLUE session could be really = helpful.  If you look at Roberta's slides from today's meeting, = there are several call flows and it would be much easier to discuss = concerns, etc with a whiteboard.  So, the doodle below is based on = a potential slot on Sunday, slots on Monday where there aren't RAI = sessions, a slot on Tuesday prior to the social and a slot on Wed. am = (another non-RAI slot, I think).   Please respond to the poll no = later than Monday, November 3rd, 2014. 

 <= /o:p>

One really = important note is that if you come to the meeting, you ought to have = read the most recent CLUE protocol document (and signaling really) as we = really want to spend focused time and not revisit basic = material.

 <= /o:p>

If we can't = manage this, we will likely schedule another design team meeting using a = collaboration tool so folks can make edits to show what they are = thinking.

 <= /o:p>

Regards,

Mary. <= o:p>

 <= /o:p>

---------- = Forwarded message ----------
From: Doodle <mailer@doodle.com>
Date: Tue, Oct 28, 2014 = at 11:57 AM
Subject: Doodle: Link for poll "CLUE Design Team - = Protocol whiteboarding"
To: Mary Barnes <mary.ietf.barnes@gmail.com>

<= div>

Hi Mary Barnes, =

  =

You have = initiated a poll "CLUE Design Team - Protocol whiteboarding" = at Doodle. The link to your poll is:

http://doodle.com/cxz9u66a545x7f7r

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

 <= /o:p>

  =

 <= /o:p>

- = Your Doodle Team

= Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich =

 <= /o:p>

 

------=_NextPart_000_08C1_01CFF2E6.5E4F02F0-- From nobody Tue Oct 28 12:29:15 2014 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 7C9E21ACD04 for ; Tue, 28 Oct 2014 12:29:09 -0700 (PDT) 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 DF0GPCWlwioL for ; Tue, 28 Oct 2014 12:29:07 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072D51AC433 for ; Tue, 28 Oct 2014 12:28:50 -0700 (PDT) Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-03v.sys.comcast.net with comcast id 8jTQ1p0075FMDhs01jUqX4; Tue, 28 Oct 2014 19:28:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id 8jUp1p00b3Ge9ey01jUqcr; Tue, 28 Oct 2014 19:28:50 +0000 Message-ID: <544FEE71.4010002@alum.mit.edu> Date: Tue, 28 Oct 2014 15:28:49 -0400 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: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> <08c001cff2d5$9ac3e900$d04bbb00$@gmail.com> In-Reply-To: <08c001cff2d5$9ac3e900$d04bbb00$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414524530; bh=Y39KF/jUP0JaVLGYXdKfwIwvArqSQk4b0nguSv/JqJ8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=r0IWyC94UzFepkLuT+bjEoOefSxzGgh1K0Bj1z5wRxiN4I9zcQ5eMjQ2RQap0CzGn 76NfENcKmdHkqKyqhFviveuHWD3dXgDv8G35M23pre5yiPTrzvhjisnjAMHkHr8qXG 5j+MeC4i0jSM/BLW2YgVfrGd/USNQUs3yhOyOFCh9C+B+C2wPBFq+MPmcH2yFFrrdl 4CgOZJh00EDGoUxwmpnSuQsyG7INLCzINUxfil6LbYEs82WBvk2wq85NVIIICVznSX y57VoxV4Gomp5K1PAYY+IRWHNzqb9pogP/Librm8qB4G9rFWbvdNgFb+vPcn29/uup MrshTbwsln+aQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cg2RBL4XcytyIv1g859gE2U3mhs Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 19:29:09 -0000 On 10/28/14 1:35 PM, Roni Even wrote: > Hi Mary, > > On Tuesday we may start earlier if we say after AVText and it finish > earlier. I wouldn't count on finishing early. Working out the details of state machines like this could take many hours. Thanks, Paul > Roni > > *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 28 October, 2014 7:22 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - > Protocol whiteboarding" > > No, I meant right after AVTEXT and just before the social. I typed in > 1520 (making the usual mistake that this is 5:20 PM and of course, the > poll converted to 3:20 pm). I updated the poll. > > On Tue, Oct 28, 2014 at 12:17 PM, Roni Even > wrote: > > Hi Mary, > > The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText. I am > not sure that this is what you meant > > Roni > > *From:*clue [mailto:clue-bounces@ietf.org > ] *On Behalf Of *Mary Barnes > *Sent:* 28 October, 2014 7:02 PM > *To:* CLUE > *Subject:* [clue] Fwd: Doodle: Link for poll "CLUE Design Team - > Protocol whiteboarding" > > During the design team call today, it was suggested that getting > together as a design team at the f2f meeting before the CLUE session > could be really helpful. If you look at Roberta's slides from today's > meeting, there are several call flows and it would be much easier to > discuss concerns, etc with a whiteboard. So, the doodle below is based > on a potential slot on Sunday, slots on Monday where there aren't RAI > sessions, a slot on Tuesday prior to the social and a slot on Wed. am > (another non-RAI slot, I think). Please respond to the poll no later > than Monday, November 3rd, 2014. > > One really important note is that if you come to the meeting, you ought > to have read the most recent CLUE protocol document (and signaling > really) as we really want to spend focused time and not revisit basic > material. > > If we can't manage this, we will likely schedule another design team > meeting using a collaboration tool so folks can make edits to show what > they are thinking. > > Regards, > > Mary. > > ---------- Forwarded message ---------- > From: *Doodle* > > Date: Tue, Oct 28, 2014 at 11:57 AM > Subject: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" > To: Mary Barnes > > > > > > > > > > > Hi Mary Barnes, > > > > > > You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at > Doodle. The link to your poll is: > > http://doodle.com/cxz9u66a545x7f7r > > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > - Your Doodle Team > > > > Doodle AG, Werdstrasse 21, 8021 Zrich > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Oct 28 12:36:49 2014 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 2DC0E1ACCEB for ; Tue, 28 Oct 2014 12:36:46 -0700 (PDT) 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 32bnvusYhDn4 for ; Tue, 28 Oct 2014 12:36:42 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5361AC43A for ; Tue, 28 Oct 2014 12:36:40 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id gq15so1312415lab.1 for ; Tue, 28 Oct 2014 12:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pDePAZkNwCmua8A1IF/9pOMTsuNBDMCjm3uilB3GAds=; b=PTR3nJznu1s6q9N+YIypvMDBuE87O2NX7ITgdUDLNTU80/D6CgezjbX2s7D2Hi0myI 1lYTUhgDyHpQnWf921bv7Og0iYqqESGwkmMPE3r4uWqknROyrz8/TgeQiEGZNGIW6w19 2uIGOTJFcUYP0HpAotBjh/ocPvDiodPgKjJmQcxq0PG4NBa2KmaqdtE6gEoMZf3uMmWW CSWU2NYsHsXVGs9QbnZu8N5l65/I2v8gy/5j+Kh7eZbJgmhbP9RZe4ZZ0f3rXafUrLPi Zkq2Z/W0tBW2U6Tq34ptNi9oxOPRzZAQH3TVQxBiqYTZOb6LbUbFs2YP1oDrgcInkA+l fXpw== MIME-Version: 1.0 X-Received: by 10.152.5.201 with SMTP id u9mr6412748lau.24.1414524998442; Tue, 28 Oct 2014 12:36:38 -0700 (PDT) Received: by 10.25.42.134 with HTTP; Tue, 28 Oct 2014 12:36:38 -0700 (PDT) In-Reply-To: <544FEE71.4010002@alum.mit.edu> References: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> <08c001cff2d5$9ac3e900$d04bbb00$@gmail.com> <544FEE71.4010002@alum.mit.edu> Date: Tue, 28 Oct 2014 14:36:38 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0141a2420ee2e4050680c494 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fpBcd15Vl3J3PavAmPdE6zHiVzM Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 19:36:46 -0000 --089e0141a2420ee2e4050680c494 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think he means that we could start the Clue meeting earlier if the AVTEXT WG session ends early. If that time slot is optimal, then yes, it would be good to tell folks that we will start about 10 minutes after AVTEXT ends. On Tue, Oct 28, 2014 at 2:28 PM, Paul Kyzivat wrote= : > On 10/28/14 1:35 PM, Roni Even wrote: > >> Hi Mary, >> >> On Tuesday we may start earlier if we say after AVText and it finish >> earlier. >> > > I wouldn't count on finishing early. Working out the details of state > machines like this could take many hours. > > Thanks, > Paul > > > Roni >> >> *From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> *Sent:* 28 October, 2014 7:22 PM >> *To:* Roni Even >> *Cc:* CLUE >> *Subject:* Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - >> Protocol whiteboarding" >> >> No, I meant right after AVTEXT and just before the social. I typed in >> 1520 (making the usual mistake that this is 5:20 PM and of course, the >> poll converted to 3:20 pm). I updated the poll. >> >> On Tue, Oct 28, 2014 at 12:17 PM, Roni Even > > wrote: >> >> Hi Mary, >> >> The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText. I am >> not sure that this is what you meant >> >> Roni >> >> *From:*clue [mailto:clue-bounces@ietf.org >> ] *On Behalf Of *Mary Barnes >> *Sent:* 28 October, 2014 7:02 PM >> *To:* CLUE >> *Subject:* [clue] Fwd: Doodle: Link for poll "CLUE Design Team - >> Protocol whiteboarding" >> >> During the design team call today, it was suggested that getting >> together as a design team at the f2f meeting before the CLUE session >> could be really helpful. If you look at Roberta's slides from today's >> meeting, there are several call flows and it would be much easier to >> discuss concerns, etc with a whiteboard. So, the doodle below is based >> on a potential slot on Sunday, slots on Monday where there aren't RAI >> sessions, a slot on Tuesday prior to the social and a slot on Wed. am >> (another non-RAI slot, I think). Please respond to the poll no later >> than Monday, November 3rd, 2014. >> >> One really important note is that if you come to the meeting, you ought >> to have read the most recent CLUE protocol document (and signaling >> really) as we really want to spend focused time and not revisit basic >> material. >> >> If we can't manage this, we will likely schedule another design team >> meeting using a collaboration tool so folks can make edits to show what >> they are thinking. >> >> Regards, >> >> Mary. >> >> ---------- Forwarded message ---------- >> From: *Doodle* > >> Date: Tue, Oct 28, 2014 at 11:57 AM >> Subject: Doodle: Link for poll "CLUE Design Team - Protocol whiteboardin= g" >> To: Mary Barnes > > >> >> >> >> >> >> >> >> >> >> Hi Mary Barnes, >> >> >> >> >> >> You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at >> Doodle. The link to your poll is: >> >> http://doodle.com/cxz9u66a545x7f7r >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally have used >> your e-mail address; simply ignore this e-mail, please.) >> >> - Your Doodle Team >> >> >> >> Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich >> >> >> >> >> >> _______________________________________________ >> 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 > --089e0141a2420ee2e4050680c494 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think he means that we could start the Clue meeting earl= ier if the AVTEXT WG session ends early. =C2=A0 If that time slot is optima= l, then yes, it would be good to tell folks that we will start about 10 min= utes after AVTEXT ends.=C2=A0

On Tue, Oct 28, 2014 at 2:28 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
= On 10/28/14 1:35 PM, Roni Even wrote:
Hi Mary,

On Tuesday we may start earlier if we say after AVText and it finish
earlier.

 I wouldn't count on finishing early. Working out the details of state m= achines like this could take many hours.

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


Roni

*From:*Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
*Sent:* 28 October, 2014 7:22 PM
*To:* Roni Even
*Cc:* CLUE
*Subject:* Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team -
Protocol whiteboarding"

No, I meant right after AVTEXT and just before the social. I typed in
1520 (making the usual mistake that this is 5:20 PM and of course, the
poll converted to 3:20 pm).=C2=A0 I updated the poll.

On Tue, Oct 28, 2014 at 12:17 PM, Roni Even <ron.even.tlv@gmail.com
<mailto:ron.= even.tlv@gmail.com>> wrote:

Hi Mary,

The slot on Tuesday in the doodle is 3:20-4:20PM which is AVText.=C2=A0 I a= m
not sure that this is what you meant

Roni

*From:*clue [mailto:clue-bounces@ietf.org
<mailto:clue-= bounces@ietf.org>] *On Behalf Of *Mary Barnes
*Sent:* 28 October, 2014 7:02 PM
*To:* CLUE
*Subject:* [clue] Fwd: Doodle: Link for poll "CLUE Design Team -
Protocol whiteboarding"

During the design team call today, it was suggested that getting
together as a design team at the f2f meeting before the CLUE session
could be really helpful.=C2=A0 If you look at Roberta's slides from tod= ay's
meeting, there are several call flows and it would be much easier to
discuss concerns, etc with a whiteboard.=C2=A0 So, the doodle below is base= d
on a potential slot on Sunday, slots on Monday where there aren't RAI sessions, a slot on Tuesday prior to the social and a slot on Wed. am
(another non-RAI slot, I think).=C2=A0 =C2=A0Please respond to the poll no = later
than Monday, November 3rd, 2014.

One really important note is that if you come to the meeting, you ought
to have read the most recent CLUE protocol document (and signaling
really) as we really want to spend focused time and not revisit basic
material.

If we can't manage this, we will likely schedule another design team meeting using a collaboration tool so folks can make edits to show what
they are thinking.

Regards,

Mary.

---------- Forwarded message ----------
 From: *Doodle* <m= ailer@doodle.com <mailto:mailer@doodle.com>>
Date: Tue, Oct 28, 2014 at 11:57 AM
Subject: Doodle: Link for poll "CLUE Design Team - Protocol whiteboard= ing"
To: Mary Barnes <mary.ietf.barnes@gmail.com
 <mailto:= mary.ietf.barnes@gmail.com>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0

<https://doodle.com/?tmail=3Dpoll_admi= n_participatelink&tlink=3Dlogo>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

Hi Mary Barnes,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

You have initiated a poll "CLUE Design Team - Protocol whiteboarding&q= uot; at
Doodle. The link to your poll is:

http://doo= dle.com/cxz9u66a545x7f7r

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

- Your Doodle Team

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0

Doodle AG, Werdstrasse 21, 8021 Z=C3=BCrich

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0



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


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

--089e0141a2420ee2e4050680c494-- From nobody Tue Oct 28 13:21:30 2014 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 BC6CD1ACE6A for ; Tue, 28 Oct 2014 13:21:24 -0700 (PDT) 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 U0AfMi7VrA8i for ; Tue, 28 Oct 2014 13:21:23 -0700 (PDT) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9617E1ACE6B for ; Tue, 28 Oct 2014 13:16:48 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-12v.sys.comcast.net with comcast id 8kGo1p0024s37d401kGoLF; Tue, 28 Oct 2014 20:16:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-01v.sys.comcast.net with comcast id 8kGn1p00C3Ge9ey01kGnsX; Tue, 28 Oct 2014 20:16:48 +0000 Message-ID: <544FF9AF.3030009@alum.mit.edu> Date: Tue, 28 Oct 2014 16:16:47 -0400 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: Mary Barnes References: <08b201cff2d3$04eff650$0ecfe2f0$@gmail.com> <08c001cff2d5$9ac3e900$d04bbb00$@gmail.com> <544FEE71.4010002@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414527408; bh=IdQo3bOz+lF48jo0Li52UW/Yv0eSrsNzQeWlQMMVRVA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KTGdPesmh6qEuBAiEdMGyQanT94wvLxqF5QTYAnPtuNvYOn0TyHgfIIePrp1dI+ej BKRUz38DNaYxFy0SZNr2CqtXoZBqBjeHMyg07zaA9cL1Fehy50hdJObtpd2TM5gWWV vDTpR15XXH4/njK4+wZgwYa0t+hoyy4CxVC5K6PIvuO/MMqdW6ciTXXZ5gSsvBbkpi A4JDmC4IA0dNS5K8ukofs4rbLNNate4iE8XYWE128BUDg5RwyGI9oSmoNqkHKP+ZFq 3/XSFPG3V64uvdbCyZ9v00UyKLyPnN6tL8UA3EtqKJwNqhPjiz0P0xuBWOZyj/Lets j8EXzCyfSd0EQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/L_gnaBoaPsElvfecrC8oXXnIhL8 Cc: CLUE Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 28 Oct 2014 20:21:25 -0000 On 10/28/14 3:36 PM, Mary Barnes wrote: > I think he means that we could start the Clue meeting earlier if the > AVTEXT WG session ends early. If that time slot is optimal, then yes, > it would be good to tell folks that we will start about 10 minutes after > AVTEXT ends. Yes, that is cool. My point was that this work probably won't be completed in one or two hours. We could probably spend a day on it if we could. We can't do that. So we won't finish. But maybe we will then have several people who are in a better position to continue the discussion online. Thanks, Paul > On Tue, Oct 28, 2014 at 2:28 PM, Paul Kyzivat > wrote: > > On 10/28/14 1:35 PM, Roni Even wrote: > > Hi Mary, > > On Tuesday we may start earlier if we say after AVText and it finish > earlier. > > > I wouldn't count on finishing early. Working out the details of > state machines like this could take many hours. > > Thanks, > Paul > > > Roni > > *From:*Mary Barnes [mailto:mary.ietf.barnes@__gmail.com > ] > *Sent:* 28 October, 2014 7:22 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - > Protocol whiteboarding" > > No, I meant right after AVTEXT and just before the social. I > typed in > 1520 (making the usual mistake that this is 5:20 PM and of > course, the > poll converted to 3:20 pm). I updated the poll. > > On Tue, Oct 28, 2014 at 12:17 PM, Roni Even > > __>> wrote: > > Hi Mary, > > The slot on Tuesday in the doodle is 3:20-4:20PM which is > AVText. I am > not sure that this is what you meant > > Roni > > *From:*clue [mailto:clue-bounces@ietf.org > > >__] > *On Behalf Of *Mary Barnes > *Sent:* 28 October, 2014 7:02 PM > *To:* CLUE > *Subject:* [clue] Fwd: Doodle: Link for poll "CLUE Design Team - > Protocol whiteboarding" > > During the design team call today, it was suggested that getting > together as a design team at the f2f meeting before the CLUE session > could be really helpful. If you look at Roberta's slides from > today's > meeting, there are several call flows and it would be much easier to > discuss concerns, etc with a whiteboard. So, the doodle below > is based > on a potential slot on Sunday, slots on Monday where there > aren't RAI > sessions, a slot on Tuesday prior to the social and a slot on > Wed. am > (another non-RAI slot, I think). Please respond to the poll no > later > than Monday, November 3rd, 2014. > > One really important note is that if you come to the meeting, > you ought > to have read the most recent CLUE protocol document (and signaling > really) as we really want to spend focused time and not revisit > basic > material. > > If we can't manage this, we will likely schedule another design team > meeting using a collaboration tool so folks can make edits to > show what > they are thinking. > > Regards, > > Mary. > > ---------- Forwarded message ---------- > From: *Doodle* > >> > Date: Tue, Oct 28, 2014 at 11:57 AM > Subject: Doodle: Link for poll "CLUE Design Team - Protocol > whiteboarding" > To: Mary Barnes > >> > > > > > > > > > > > Hi Mary Barnes, > > > > > > You have initiated a poll "CLUE Design Team - Protocol > whiteboarding" at > Doodle. The link to your poll is: > > http://doodle.com/__cxz9u66a545x7f7r > > > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally > have used > your e-mail address; simply ignore this e-mail, please.) > > - Your Doodle Team > > > > Doodle AG, Werdstrasse 21, 8021 Zürich > > > > > > _________________________________________________ > 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 Oct 28 15:38:27 2014 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 566C01A0030 for ; Tue, 28 Oct 2014 15:38:24 -0700 (PDT) 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 UIl1ZbYP_kEz for ; Tue, 28 Oct 2014 15:38:21 -0700 (PDT) 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 9E3891A0027 for ; Tue, 28 Oct 2014 15:38:21 -0700 (PDT) Received: from ppp118-209-0-107.lns20.mel4.internode.on.net ([118.209.0.107]:51168 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjFO1-00020X-8C for clue@ietf.org; Wed, 29 Oct 2014 09:37:09 +1100 Message-ID: <54501AD2.8010303@nteczone.com> Date: Wed, 29 Oct 2014 09:38:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D4D0C03@ESESSMB209.ericsson.se> 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/99qMcXnIpHH2sTmQpe0vXInbfuo Subject: Re: [clue] CLUE Design team meeting is on today 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, 28 Oct 2014 22:38:24 -0000 I sent my regrets when I switched to Summer time :-) Christian On 29/10/2014 12:59 AM, Mary Barnes wrote: > Oh yeah, I ought to have sent a reminder about that as well. > > On Tue, Oct 28, 2014 at 8:20 AM, Christer Holmberg > > wrote: > > We switched to winter time a few days ago, so I thought we wont > begin until one hour > > Ill call in. > > *From:*clue [mailto:clue-bounces@ietf.org > ] *On Behalf Of *Mary Barnes > *Sent:* 28. lokakuuta 2014 15:10 > *To:* CLUE > *Subject:* [clue] CLUE Design team meeting is on today > > We are currently discussing the protocol. There are only 4 of us > on the call - 2 chairs, the presenter (Roberta) and Mark. (Note: > that one person (Rob) did send his regrets). It would be a good > idea if others could join so we're not just having to repeat this > in HNL. > > Thanks, > > Mary > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Oct 29 11:20:42 2014 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 9724C1A877F for ; Wed, 29 Oct 2014 11:20:30 -0700 (PDT) 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 ewgHA7wO98go for ; Wed, 29 Oct 2014 11:20:29 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBBD71A8784 for ; Wed, 29 Oct 2014 11:20:28 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-10v.sys.comcast.net with comcast id 96L91p0054vw8ds016LUFh; Wed, 29 Oct 2014 18:20:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id 96LT1p00U3Ge9ey016LUWh; Wed, 29 Oct 2014 18:20:28 +0000 Message-ID: <54512FEB.5010603@alum.mit.edu> Date: Wed, 29 Oct 2014 14:20:27 -0400 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414606828; bh=bU9B4H+xpwC03gTDi5qSz1GPvwMCc23cxV1VIQTtePY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=U7eJ8UcU5cG5fgbcZmzM6gNuqDdoMQmKrriOrUqZhK+f66I9d0pFJ/HSdaIsJr9rq qSlVWfWIXhAlrCx0y5pkiCSAOHdH2mx2Myd1WSmZ6v9DzZsKvTd1j9D+TRh28Gy7et GnUos9Mcx3r2sCbKsapwneyyqrrTTnHtfrFcZ6dY1ulT0I0yEinly25BHT+hxgycup bimLbjQNxgD/gb36Q5/It6QDUILoTtF0B4YnXfAOGNH1MSOeNr9wce+DSBHYjEPy6e hCacubQfF8z1zg+bZWPmFKQWXZEBNjUPHpVzlg9bOoIV6bYCECR1cd87yssVpUWZcP IUUzTgbs88BVQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VacAWsoMEH6H0MJ5rSPvRa7-ZZc Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 29 Oct 2014 18:20:30 -0000 So far we have Mary and I, Roni and Christer. And there is only one slot that isn't a NO for anyone. But we don't have Simon/Roberta. Without one of them there is probably no point. Roberta - will you be in Honolulu? Or is Simon reserving the *good* trips for himself? :-) Thanks, Paul On 10/28/14 1:02 PM, Mary Barnes wrote: > You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at > Doodle. The link to your poll is: > > http://doodle.com/cxz9u66a545x7f7r > > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) From nobody Wed Oct 29 11:51:10 2014 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 DBCB71A8853 for ; Wed, 29 Oct 2014 11:51:07 -0700 (PDT) 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 fEIA8GjiTZio for ; Wed, 29 Oct 2014 11:51:06 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E331A8846 for ; Wed, 29 Oct 2014 11:51:05 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-11v.sys.comcast.net with comcast id 96qd1p0055E3ZMc016r5Qi; Wed, 29 Oct 2014 18:51:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id 96r41p0083Ge9ey016r4WP; Wed, 29 Oct 2014 18:51:05 +0000 Message-ID: <54513718.7090209@alum.mit.edu> Date: Wed, 29 Oct 2014 14:51:04 -0400 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 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=1414608665; bh=Ae92I8VLcwxR7AVdmOOra9rjdE38XARO8k/PYOsIciI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KodQLQR0kkmS32YbEEh96fulBkiRBMSjeBnKcilJx4Om4BLbfnGvI23VVYeChLmuW ZjYxEXFy1D3MNvba4JXc3G7Kayr8lq5VYrXEjAHSA2AERnaiBk0mfi0vv9COu8yhDR 6u/dtifRH3BfUckeMlsmpuWf9PJurFxMW6PWYTRC64f7+33H3qzc5fKZxz6BRjf2v3 6UWaq9gr6Tl5BaHYczDemjo3OCOabq+CeWKazDky+sGm9WdPWE4AZqIyoBbJAtcVRQ 0by/igIi1REziZCU7IAq8N0QeH8CQ/CHXsCsnczl3mImfjUzVgDYJU0UXBuD1AJPo5 iWCNCAYyXuIog== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NKbVHvymulmARScWg083SzMOTYo Subject: [clue] CLUE agenda for IETF91 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, 29 Oct 2014 18:51:08 -0000 You can find a very preliminary agenda for our CLUE sessions at IETF91: http://www.ietf.org/proceedings/91/agenda/agenda-91-clue I tried to prioritize those things that need the most work, and that have had recent action. Note that for now I gave no time to the call flows, because there have been no changes since the last meeting. For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? I request that all authors/presenters please review this and consider how much time you can effectively use. We don't have enough discretionary time for followup, so if you don't need as much time as I allotted please let me know. And note that the agenda needs to be finalized by Monday, so I need your feedback before then. Thanks, Paul From nobody Wed Oct 29 15:28:39 2014 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 1C8FD1AC3A8 for ; Wed, 29 Oct 2014 15:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 m8_vl0xYGZN3 for ; Wed, 29 Oct 2014 15:28:35 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102111AC3A6 for ; Wed, 29 Oct 2014 15:28:34 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so2728513wiv.4 for ; Wed, 29 Oct 2014 15:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=Lwo4C4cszAGQwikXdUSGOiqIWOvS6F5gkywsYopzflM=; b=H1oCCtde+UguBWLaN3aD0UzlEZ4bR0KEDaJ8QgYkgANGm9liknxTS/K5fGZZ8mJEst hr45DsQa9YQT1awceiWaSqUKq3UvSb/Z9Q+z4EOF90fgEamdwixVhiiLuEHi/HFWsQsH 5PsXuU3UvovIQUYbpvaa4TvOrxAczDPwLWy5xFYDpSmIDtuvZQ4J8Ht3X4mIk578+QC2 2pMrfh+k3E3DEllx49TtxsYSZNoWupOhkdxIJ7f6fFfSIjzlJ9Hsnckn+M6D5S28XY2q We2B2iEROtkodMayiHZpFdYrCRaYk1MR8LRjsWFOl+jBY5cnulk6/UjybSAzJsYHPYRy 3D9w== X-Received: by 10.180.76.199 with SMTP id m7mr27985273wiw.62.1414621713626; Wed, 29 Oct 2014 15:28:33 -0700 (PDT) Received: from RoniE (bzq-79-179-96-40.red.bezeqint.net. [79.179.96.40]) by mx.google.com with ESMTPSA id t16sm6597124wjr.44.2014.10.29.15.28.31 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Oct 2014 15:28:32 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , "'CLUE'" References: <54513718.7090209@alum.mit.edu> In-Reply-To: <54513718.7090209@alum.mit.edu> Date: Thu, 30 Oct 2014 00:28:28 +0200 Message-ID: <09ea01cff3c7$ab4fd110$01ef7330$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQC/vi5JArCnWlZAAMcQjOSkn6RhF55oEheQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/0MFkCwp6oaqhSp81MlA_hwP4Tzc Subject: Re: [clue] CLUE agenda for IETF91 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, 29 Oct 2014 22:28:37 -0000 Hi Paul, I noticed that call flows is mentioned but with 0 time and I am now trying to figure out how fast I need to talk As for RTP mapping I will do the presentation Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 29 October, 2014 8:51 PM > To: CLUE > Subject: [clue] CLUE agenda for IETF91 > > You can find a very preliminary agenda for our CLUE sessions at IETF91: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue > > I tried to prioritize those things that need the most work, and that have had > recent action. > > Note that for now I gave no time to the call flows, because there have been no > changes since the last meeting. > > For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? > > I request that all authors/presenters please review this and consider how much > time you can effectively use. We don't have enough discretionary time for > followup, so if you don't need as much time as I allotted please let me know. > > And note that the agenda needs to be finalized by Monday, so I need your > feedback before then. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Oct 29 19:52:56 2014 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 842631ACFF2 for ; Wed, 29 Oct 2014 19:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 70CMgG8dSsC9 for ; Wed, 29 Oct 2014 19:52:50 -0700 (PDT) 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 EC2271ACFF0 for ; Wed, 29 Oct 2014 19:52:49 -0700 (PDT) Received: from ppp118-209-219-103.lns20.mel8.internode.on.net ([118.209.219.103]:60222 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XjfpY-0007Zp-OP for clue@ietf.org; Thu, 30 Oct 2014 13:51:20 +1100 Message-ID: <5451A7F4.7070804@nteczone.com> Date: Thu, 30 Oct 2014 13:52:36 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> <544F9257.1090207@unina.it> <544FB35C.80706@alum.mit.edu> In-Reply-To: <544FB35C.80706@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zB8pyDDK0kgslzHCcaVEAzY16yo Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 02:52:55 -0000 Hello Paul and Roberta, > >>> Why has READV been *removed*? Has something changed so that we don't >>> need it? (I was advocating for renaming it, not removing it.) >>> >> While reviewing the state machines, we found the message redundant in >> each case where in the past we thought it could be useful. It is one of >> the topic of the today's discussion. > > Based on discussion in design team call today I agree that we don't > seem to need it. [CNG] I thought READV the message was needed in case the MP lost the CLUE data model information and needed an update. It allowed the MP to request an update from the MC. If we remove that what is now the assumption? Can you elaborate, as I wasn't in the meeting? Regards, Christian From nobody Wed Oct 29 19:56:28 2014 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 EC79C1ACFF4 for ; Wed, 29 Oct 2014 19:56:26 -0700 (PDT) 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 NxpWpKbnUbmr for ; Wed, 29 Oct 2014 19:56:22 -0700 (PDT) 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 A25871ACFEF for ; Wed, 29 Oct 2014 19:56:22 -0700 (PDT) Received: from ppp118-209-219-103.lns20.mel8.internode.on.net ([118.209.219.103]:60268 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Xjft0-00088V-Q8 for clue@ietf.org; Thu, 30 Oct 2014 13:54:54 +1100 Message-ID: <5451A8CA.8020809@nteczone.com> Date: Thu, 30 Oct 2014 13:56:10 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <54513718.7090209@alum.mit.edu> In-Reply-To: <54513718.7090209@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/r6oO1EQIzSvYkL4QSoIC-7I-TzA Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 02:56:27 -0000 Hello Paul, You may want to double check the draft versions on the agenda. E.g. the framework is v18, the datachannel draft is v2 etc. Regards, Christian On 30/10/2014 5:51 AM, Paul Kyzivat wrote: > You can find a very preliminary agenda for our CLUE sessions at IETF91: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue > > I tried to prioritize those things that need the most work, and that > have had recent action. > > Note that for now I gave no time to the call flows, because there have > been no changes since the last meeting. > > For the RTP Mapping, who will be leading the discussion? Roni or > Jonathan? > > I request that all authors/presenters please review this and consider > how much time you can effectively use. We don't have enough > discretionary time for followup, so if you don't need as much time as > I allotted please let me know. > > And note that the agenda needs to be finalized by Monday, so I need > your feedback before then. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 30 00:34:45 2014 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 0E0E91AD042 for ; Thu, 30 Oct 2014 00:34:44 -0700 (PDT) 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 HW9xRLyIlAhS for ; Thu, 30 Oct 2014 00:34:41 -0700 (PDT) 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 DD45A1AD038 for ; Thu, 30 Oct 2014 00:34:40 -0700 (PDT) X-ASG-Debug-ID: 1414654477-05ce3723b76c8c80001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id jJlB1ARtGpHFF2Ad (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:34:37 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [1.32.89.36] ([91.252.4.12]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s9U7YYh5011091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:34:37 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <54513718.7090209@alum.mit.edu> References: <54513718.7090209@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YF7ZG3HKPHP09MGL7M3Z7DKPDU3K7Z" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE agenda for IETF91 Date: Thu, 30 Oct 2014 08:34:30 +0100 To: Paul Kyzivat , CLUE Message-ID: X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1414654477 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 1.32.89.36 as permitted sender) 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=BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11042 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2LEwQ32YFzQriI-hUwpy6Gub50U Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 07:34:44 -0000 ------YF7ZG3HKPHP09MGL7M3Z7DKPDU3K7Z Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Paul, I think that a total of 1 hour is enough for presenting both the protocol and the data model drafts. Simon Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat ha scritto: >You can find a very preliminary agenda for our CLUE sessions at IETF91: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue > >I tried to prioritize those things that need the most work, and that >have had recent action. > >Note that for now I gave no time to the call flows, because there have >been no changes since the last meeting. > >For the RTP Mapping, who will be leading the discussion? Roni or >Jonathan? > >I request that all authors/presenters please review this and consider >how much time you can effectively use. We don't have enough >discretionary time for followup, so if you don't need as much time as I > >allotted please let me know. > >And note that the agenda needs to be finalized by Monday, so I need >your >feedback before then. > > Thanks, > Paul > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------YF7ZG3HKPHP09MGL7M3Z7DKPDU3K7Z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Paul,

I think that a total of 1 hour is enough for presenting both the protocol and the data model drafts.

Simon

Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
You can find a very preliminary agenda for our CLUE sessions at IETF91:

     http://www.ietf.org/proceedings/91/agenda/agenda-91-clue

I tried to prioritize those things that need the most work, and that 
have had recent action.

Note that for now I gave no time to the call flows, because there have 
been no changes since the last meeting.

For the RTP Mapping, who will be leading the discussion? Roni or Jonathan?

I request that all authors/presenters please review this and consider 
how much time you can effectively use. We don't have enough 
discretionary time for followup, so if you don't need as much time as I 
allotted please let me know.

And note that the agenda needs to be finalized by Monday, so I need your 
feedback before then.

	Thanks,
	Paul


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

------YF7ZG3HKPHP09MGL7M3Z7DKPDU3K7Z-- From nobody Thu Oct 30 00:52:12 2014 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 DBC491AD03D for ; Thu, 30 Oct 2014 00:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.37 X-Spam-Level: * X-Spam-Status: No, score=1.37 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 HHQIfI14kacb for ; Thu, 30 Oct 2014 00:52:09 -0700 (PDT) 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 62C7A1AD03A for ; Thu, 30 Oct 2014 00:52:09 -0700 (PDT) X-ASG-Debug-ID: 1414655526-05ce3723b56c9b50001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id bZiV41RhFht4xDCV (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:52:07 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [1.32.89.36] ([91.252.4.12]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s9U7q56D013187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 08:52:06 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <54512FEB.5010603@alum.mit.edu> References: <54512FEB.5010603@alum.mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F8LWC6KQNN296DYTSKD2MUPLEF2028" Content-Transfer-Encoding: 8bit From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" Date: Thu, 30 Oct 2014 08:51:59 +0100 To: Paul Kyzivat , clue@ietf.org Message-ID: X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1414655527 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 1.32.89.36 as permitted sender) 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=BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11043 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TLo1HfY7vQHRg9RJy60e3bZop8E Subject: Re: [clue] Fwd: Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 30 Oct 2014 07:52:11 -0000 ------F8LWC6KQNN296DYTSKD2MUPLEF2028 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi Paul, I'm the only one who will be in Honolulu. Unfortunately Roberta could not make it :-(. I'm trying to figure out how to take enough time out of the Meetecho schedule in order to participate in the 'whiteboarding' meeting. By today EOB I'll fill in the poll. Simon Il 29 ottobre 2014 19:20:27 CET, Paul Kyzivat ha scritto: >So far we have Mary and I, Roni and Christer. And there is only one >slot >that isn't a NO for anyone. But we don't have Simon/Roberta. Without >one >of them there is probably no point. > >Roberta - will you be in Honolulu? >Or is Simon reserving the *good* trips for himself? :-) > > Thanks, > Paul > >On 10/28/14 1:02 PM, Mary Barnes wrote: > >> You have initiated a poll "CLUE Design Team - Protocol whiteboarding" >at >> Doodle. The link to your poll is: >> >> http://doodle.com/cxz9u66a545x7f7r >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally have >used >> your e-mail address; simply ignore this e-mail, please.) > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue ------F8LWC6KQNN296DYTSKD2MUPLEF2028 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Paul,

I'm the only one who will be in Honolulu. Unfortunately Roberta could not make it :-(. I'm trying to figure out how to take enough time out of the Meetecho schedule in order to participate in the 'whiteboarding' meeting. By today EOB I'll fill in the poll.

Simon

Il 29 ottobre 2014 19:20:27 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> ha scritto:
So far we have Mary and I, Roni and Christer. And there is only one slot 
that isn't a NO for anyone. But we don't have Simon/Roberta. Without one 
of them there is probably no point.

Roberta - will you be in Honolulu?
Or is Simon reserving the *good* trips for himself? :-)

	Thanks,
	Paul

On 10/28/14 1:02 PM, Mary Barnes wrote:

 You have initiated a poll "CLUE Design Team - Protocol whiteboarding" at
 Doodle. The link to your poll is:

 http://doodle.com/cxz9u66a545x7f7r

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


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

------F8LWC6KQNN296DYTSKD2MUPLEF2028-- From nobody Thu Oct 30 03:04:38 2014 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 054011AD01B for ; Thu, 30 Oct 2014 03:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 5LZDUhl12m5Y for ; Thu, 30 Oct 2014 03:04:33 -0700 (PDT) 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 70C581AD0A1 for ; Thu, 30 Oct 2014 03:04:33 -0700 (PDT) X-ASG-Debug-ID: 1414663378-05f2757f32698030001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id AlvOwXEBLWOXPbNd (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 11:02:58 +0100 (CET) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([143.225.229.171]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s9UA2vSv030488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 30 Oct 2014 11:02:58 +0100 Message-ID: <54520CD3.5060403@unina.it> Date: Thu, 30 Oct 2014 11:02:59 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org, Christian Groves References: <20141024131007.25439.32459.idtracker@ietfa.amsl.com> <544A5742.6050606@unina.it> <544EA871.6010507@alum.mit.edu> <544F9257.1090207@unina.it> <544FB35C.80706@alum.mit.edu> <5451A7F4.7070804@nteczone.com> X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt In-Reply-To: <5451A7F4.7070804@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1414663378 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= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.11045 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZrJcU0lSNTRVoqi3OhV6j4lVjoc Subject: Re: [clue] I-D Action: draft-ietf-clue-protocol-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:04:36 -0000 Hello Christian, we found that with the current state machines, in any case the MC might need a new copy of the ADV, that copy will arrive even without asking for it. We considered: - when there might be channel errors for example, or end of session events; - when the received ADV is nacked by the MC; - when the MP does not receive any ACK (/NACK/CONF) from the MC In each of the aforementioned situations, what happens is that the MP (sooner or later, thanks to a retry mechanism) will send a new ADV to the MC and that the MC will be reached by that ADV. What is your feeling about these considerations? Regards, Roberta Il 30/10/2014 03:52, Christian Groves ha scritto: > Hello Paul and Roberta, > >> >>>> Why has READV been *removed*? Has something changed so that we don't >>>> need it? (I was advocating for renaming it, not removing it.) >>>> >>> While reviewing the state machines, we found the message redundant in >>> each case where in the past we thought it could be useful. It is >>> one of >>> the topic of the today's discussion. >> >> Based on discussion in design team call today I agree that we don't >> seem to need it. > > [CNG] I thought READV the message was needed in case the MP lost the > CLUE data model information and needed an update. It allowed the MP to > request an update from the MC. If we remove that what is now the > assumption? Can you elaborate, as I wasn't in the meeting? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 30 06:35:44 2014 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 A8C7C1AD248 for ; Thu, 30 Oct 2014 06:35:40 -0700 (PDT) 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 cdc95ErSMaQx for ; Thu, 30 Oct 2014 06:35:38 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B4A1AD26E for ; Thu, 30 Oct 2014 06:34:26 -0700 (PDT) Received: from [216.82.254.20] by server-3.bemta-7.messagelabs.com id 4F/68-02952-26E32545; Thu, 30 Oct 2014 13:34:26 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-47.messagelabs.com!1414676065!13364366!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28013 invoked from network); 30 Oct 2014 13:34:26 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 30 Oct 2014 13:34:26 -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, 30 Oct 2014 06:34:25 -0700 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 30 Oct 2014 06:34:25 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , CLUE Date: Thu, 30 Oct 2014 06:34:23 -0700 Thread-Topic: [clue] CLUE agenda for IETF91 Thread-Index: Ac/zqVAy4qO6mdHtQjWZQ3JQI4nLfwAnJSpQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968D9B5BBB@CRPMBOXPRD08.polycom.com> References: <54513718.7090209@alum.mit.edu> In-Reply-To: <54513718.7090209@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: http://mailarchive.ietf.org/arch/msg/clue/xtSCpZtPownMDdcA4syOas3vZaU Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 13:35:40 -0000 Hi Paul, I think Framework needs only 5 or 10 minutes, as there is only one open iss= ue and that is really an RTP mapping issue. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, October 29, 2014 2:51 PM > To: CLUE > Subject: [clue] CLUE agenda for IETF91 >=20 > You can find a very preliminary agenda for our CLUE sessions at IETF91: >=20 > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue >=20 > I tried to prioritize those things that need the most work, and that > have had recent action. >=20 > Note that for now I gave no time to the call flows, because there have > been no changes since the last meeting. >=20 > For the RTP Mapping, who will be leading the discussion? Roni or Jonathan= ? >=20 > I request that all authors/presenters please review this and consider > how much time you can effectively use. We don't have enough > discretionary time for followup, so if you don't need as much time as I > allotted please let me know. >=20 > And note that the agenda needs to be finalized by Monday, so I need your > feedback before then. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Oct 30 07:14:20 2014 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 44C201AD38A for ; Thu, 30 Oct 2014 07:14:10 -0700 (PDT) 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 7d_umMSVJzXG for ; Thu, 30 Oct 2014 07:14:04 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289741AD37F for ; Thu, 30 Oct 2014 07:14:02 -0700 (PDT) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-10v.sys.comcast.net with comcast id 9SCv1p001516pyw01SE1kk; Thu, 30 Oct 2014 14:14:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id 9SE01p00h3Ge9ey01SE1rM; Thu, 30 Oct 2014 14:14:01 +0000 Message-ID: <545247A8.60101@alum.mit.edu> Date: Thu, 30 Oct 2014 10:14:00 -0400 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: Roni Even , 'CLUE' References: <54513718.7090209@alum.mit.edu> <09ea01cff3c7$ab4fd110$01ef7330$@gmail.com> In-Reply-To: <09ea01cff3c7$ab4fd110$01ef7330$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414678441; bh=FHzO0dgfjjmV21PZchjm353UHxIJdP8J2l/TpifOwm8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ryPfRfTFU8nX6TPvMPYXb8xXQ5P5Ufyru+smc4zeaPcpIH4LK/yT4Fg2fAYV1UEbE dcNHMUT1hxpp+0llvXQFJbThRpGxWMAIOhsP5B5cVMxUwtgarCiSuChOL7hKuN8A0q cEfpHWwJu8rfduLlgjvuZd8LyYmMKDziii8yWss0mo+XEDSIU5/rWgkW0uuDxoKP4f 4CdCaYO6Am7pf3Up2MNqV21UHLkKszWXKw8QQI+Fy8D6YzG+qkyQe10gdWZECO+UA1 vRcAB6YCLgcpHcXcUHCjREFfvb+zJpZVj76DzzeWWEMeQS4p/Ut2NNw5/i94vzAFKc dsEk+4ZXfePUw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ukfcy8dhjqmwFpPVzETKYFLguEQ Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 14:14:11 -0000 On 10/29/14 6:28 PM, Roni Even wrote: > Hi Paul, > I noticed that call flows is mentioned but with 0 time and I am now trying > to figure out how fast I need to talk I put it in the agenda as a placeholder. I explained in my message that I gave it no time because AFAIK there have been no changes, and no list discussion, since the last meeting. So it doesn't meet the usual criteria for agenda time. It is pretty late for a new version and list discussion now, before the meeting. How much time would you want, and how would you use that time? Any time it gets will come from something else. Thanks, Paul > As for RTP mapping I will do the presentation > > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 29 October, 2014 8:51 PM >> To: CLUE >> Subject: [clue] CLUE agenda for IETF91 >> >> You can find a very preliminary agenda for our CLUE sessions at IETF91: >> >> http://www.ietf.org/proceedings/91/agenda/agenda-91-clue >> >> I tried to prioritize those things that need the most work, and that have > had >> recent action. >> >> Note that for now I gave no time to the call flows, because there have > been no >> changes since the last meeting. >> >> For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? >> >> I request that all authors/presenters please review this and consider how > much >> time you can effectively use. We don't have enough discretionary time for >> followup, so if you don't need as much time as I allotted please let me > know. >> >> And note that the agenda needs to be finalized by Monday, so I need your >> feedback before then. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Thu Oct 30 07:15:06 2014 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 B5B891A00D4 for ; Thu, 30 Oct 2014 07:15:01 -0700 (PDT) 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 onKFR38eADay for ; Thu, 30 Oct 2014 07:15:00 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443221A0024 for ; Thu, 30 Oct 2014 07:15:00 -0700 (PDT) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-09v.sys.comcast.net with comcast id 9SE91p0024zp9eg01SEzsV; Thu, 30 Oct 2014 14:14:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-07v.sys.comcast.net with comcast id 9SEz1p00F3Ge9ey01SEziQ; Thu, 30 Oct 2014 14:14:59 +0000 Message-ID: <545247E3.2070305@alum.mit.edu> Date: Thu, 30 Oct 2014 10:14:59 -0400 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: <54513718.7090209@alum.mit.edu> <5451A8CA.8020809@nteczone.com> In-Reply-To: <5451A8CA.8020809@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=1414678499; bh=Q1dtdLyC4uemBazz1qCMSNZrovEKNZem332hrYKzKy8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=LnlXSxj8ORiRTU4FFJiMxzyJGW1ojAwRyQDIwMWE+EuMzQn3PYydzXB0kPbaITc6z 8IiLtSewB+CuqYp8DgAw4IsmdtWzeZvoHqU/p9Lde+XcLnKZ4lv8OvPkHWhkld+ddm 5fwxdiaPDopI9mnc5c+QxXuNnMy7ofD47K+PhsUpF1sxFq1OOxpbAenE1el4OuWgUm 6F5Ll+Za3Q4DC83s19OYDutQLmCbGU4O7k3rAxMEty0wbz6NO3//BuCh7JG0ff/D4t 02w6oRicdK3agy5qPosixRh9udKiYT2eTzXu6k3kAXokCJZRjBC1l6e9renA61rdtw xyoOW7bYGw3WA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_1lw0ytRsyocOHE3yIldL1Q4zk8 Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 14:15:03 -0000 On 10/29/14 10:56 PM, Christian Groves wrote: > Hello Paul, > > You may want to double check the draft versions on the agenda. E.g. the > framework is v18, the datachannel draft is v2 etc. Ah! Good point. I did cut/paste and edit on the agenda from last time and didn't update those. :-( Thanks, Paul > Regards, Christian > > On 30/10/2014 5:51 AM, Paul Kyzivat wrote: >> You can find a very preliminary agenda for our CLUE sessions at IETF91: >> >> http://www.ietf.org/proceedings/91/agenda/agenda-91-clue >> >> I tried to prioritize those things that need the most work, and that >> have had recent action. >> >> Note that for now I gave no time to the call flows, because there have >> been no changes since the last meeting. >> >> For the RTP Mapping, who will be leading the discussion? Roni or >> Jonathan? >> >> I request that all authors/presenters please review this and consider >> how much time you can effectively use. We don't have enough >> discretionary time for followup, so if you don't need as much time as >> I allotted please let me know. >> >> And note that the agenda needs to be finalized by Monday, so I need >> your feedback before then. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 30 07:17:08 2014 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 EB16A1AD395 for ; Thu, 30 Oct 2014 07:16:55 -0700 (PDT) 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 f9mWg5Hl8WPr for ; Thu, 30 Oct 2014 07:16:53 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035741AD3B3 for ; Thu, 30 Oct 2014 07:16:44 -0700 (PDT) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-11v.sys.comcast.net with comcast id 9SFT1p0015E3ZMc01SGkhy; Thu, 30 Oct 2014 14:16:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id 9SGj1p00N3Ge9ey01SGkgZ; Thu, 30 Oct 2014 14:16:44 +0000 Message-ID: <54524848.3060000@alum.mit.edu> Date: Thu, 30 Oct 2014 10:16:40 -0400 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: Simon Pietro Romano , CLUE References: <54513718.7090209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414678604; bh=aDjFuPeRPrRCOIOZT9xwb2tqO+VdbfX43ZrDOLf3P+k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QOjYfe5dtEcTb2T5/T2qk6MyqzZtZdsA0HFTmX2Yp70O2kbxnRCqXw9Im5eQu+2+S +g+u0mCHy+TfRlXEtI2pcleQ/0Z6he2B41nygPnaJSuiioZR46oFB4gAOR6m/ZEdRk WbJOgrxvo0auv9y7OvunHa0l+NesVSRnSaNpIr7x6HN+DrXPnpizGybdZQos5FubJ3 GSvx1htdJfFJ/F3FMTGs+LqUbb4+/m9j0DIU9xkXxmH/uRhG4O6COSVSqeLBmPIbBJ 35G2978b+mHv/mkwQIoN+VraMYu3nTsmcFoqVk9LdIqWlKu4LyoVbWyo2dl2hEknlx gxRJ6pS0ExhCQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/deEVxb1_rz9I3ZaxcTbjXu9Blas Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 14:16:56 -0000 On 10/30/14 3:34 AM, Simon Pietro Romano wrote: > Hi Paul, > > I think that a total of 1 hour is enough for presenting both the > protocol and the data model drafts. OK. While it is perhaps arbitrary, how would you like the time split between the two? Thanks, Paul > Simon > > Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat ha > scritto: > > You can find a very preliminary agenda for our CLUE sessions at IETF91: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue > > I tried to prioritize those things that need the most work, and that > have had recent action. > > Note that for now I gave no time to the call flows, because there have > been no changes since the last meeting. > > For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? > > I request that all authors/presenters please review this and consider > how much time you can effectively use. We don't have enough > discretionary time for followup, so if you don't need as much time as I > allotted please let me know. > > And note that the agenda needs to be finalized by Monday, so I need your > feedback before then. > > Thanks, > Paul > > ------------------------------------------------------------------------ > > clue > > mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 30 07:28:33 2014 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 3B2A81AD0C1 for ; Thu, 30 Oct 2014 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.67 X-Spam-Level: ** X-Spam-Status: No, score=2.67 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 lUlM5YXKlKkW for ; Thu, 30 Oct 2014 07:28:29 -0700 (PDT) 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 77A0B1AD39F for ; Thu, 30 Oct 2014 07:28:22 -0700 (PDT) X-ASG-Debug-ID: 1414679300-05ce3723b76e9110001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id fDEviCmOleNVAVJm (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 15:28:20 +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 s9UESJMZ003371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Oct 2014 15:28:19 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_06D16CC5-21A5-41F4-BE09-8B60D5587F66" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE agenda for IETF91 In-Reply-To: <54524848.3060000@alum.mit.edu> Date: Thu, 30 Oct 2014 15:28:14 +0100 Message-Id: <4D109B2F-5509-4859-8453-C081B4881422@unina.it> References: <54513718.7090209@alum.mit.edu> <54524848.3060000@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1878.6) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1414679300 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.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.11049 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/sHIOw2eSufS6M2filKxmeQYg_bY Cc: CLUE Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 14:28:31 -0000 --Apple-Mail=_06D16CC5-21A5-41F4-BE09-8B60D5587F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Paul, > OK. While it is perhaps arbitrary, how would you like the time split = between the two? 50 minutes for the protocol and 10 for the data model. Thanks, Simon >=20 > Thanks, > Paul >=20 >> Simon >>=20 >> Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat = ha >> scritto: >>=20 >> You can find a very preliminary agenda for our CLUE sessions at = IETF91: >>=20 >> http://www.ietf.org/proceedings/91/agenda/agenda-91-clue >>=20 >> I tried to prioritize those things that need the most work, and = that >> have had recent action. >>=20 >> Note that for now I gave no time to the call flows, because there = have >> been no changes since the last meeting. >>=20 >> For the RTP Mapping, who will be leading the discussion? Roni or = Jonathan? >>=20 >> I request that all authors/presenters please review this and = consider >> how much time you can effectively use. We don't have enough >> discretionary time for followup, so if you don't need as much time = as I >> allotted please let me know. >>=20 >> And note that the agenda needs to be finalized by Monday, so I = need your >> feedback before then. >>=20 >> Thanks, >> Paul >>=20 >> = ------------------------------------------------------------------------ >>=20 >> clue >>=20 >> mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_06D16CC5-21A5-41F4-BE09-8B60D5587F66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Paul,

OK. = While it is perhaps arbitrary, how would you like the time split between = the two?

50 minutes for the = protocol and 10 for the data = model.

Thanks,

Simon

= Thanks,
Paul

Simon

Il 29 = ottobre 2014 19:51:04 CET, Paul Kyzivat <pkyzivat@alum.mit.edu> = ha
scritto:

   You can find a very preliminary = agenda for our CLUE sessions at = IETF91:

         http://w= ww.ietf.org/proceedings/91/agenda/agenda-91-clue

  &n= bsp;I tried to prioritize those things that need the most work, and = that
   have had recent = action.

   Note that for now I gave no time to the = call flows, because there have
   been no changes = since the last meeting.

   For the RTP Mapping, = who will be leading the discussion? Roni or = Jonathan?

   I request that all authors/presenters = please review this and consider
   how much time you = can effectively use. We don't have = enough
   discretionary time for followup, so if you = don't need as much time as I
   allotted please let me = know.

   And note that the agenda needs to be = finalized by Monday, so I need your
   feedback before = then.

    = Thanks,
    = Paul

   -------------------------------------= -----------------------------------

   clue

&= nbsp;  mailing list
   clue@ietf.org
   https://www.ietf.org/m= ailman/listinfo/clue

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

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






= --Apple-Mail=_06D16CC5-21A5-41F4-BE09-8B60D5587F66-- From nobody Thu Oct 30 07:38:18 2014 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 A40421A00E6 for ; Thu, 30 Oct 2014 07:38:15 -0700 (PDT) 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 KyfBDRJCjug2 for ; Thu, 30 Oct 2014 07:38:14 -0700 (PDT) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77AC31AD399 for ; Thu, 30 Oct 2014 07:38:12 -0700 (PDT) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-03v.sys.comcast.net with comcast id 9Se51p0054vw8ds01SeCuE; Thu, 30 Oct 2014 14:38:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-04v.sys.comcast.net with comcast id 9SeA1p00M3Ge9ey01SeAYT; Thu, 30 Oct 2014 14:38:11 +0000 Message-ID: <54524D52.6020504@alum.mit.edu> Date: Thu, 30 Oct 2014 10:38:10 -0400 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: <54513718.7090209@alum.mit.edu> In-Reply-To: <54513718.7090209@alum.mit.edu> 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=1414679892; bh=BxSmsxE7TqgOg9daDdxOISjOWdaz7q3/UECRLmuBQBs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pxMHX5aHZeEQHQJF6aXrF9spLXmDdaFJ3fokQ1rC+skpwzanBz+M7VAIs7S1ejdZ6 XTqCWP1s619GQnRS/btqFLCvPXiPDHwqNsX438ns8hTou1yX+Tr4LU/Vts4Kpr9Iuh NC8oMNoz2Z1NnUdK4sPw3qkQRsq4eWVJM4RxSqZ0rz8iBzIOL9tvbWHb6Hl7eIL+hW D78SKz9K4j8Z9Z2+XLSDwfelYrrOZ0IGEjpBwf0vH/JfLphyL89OizkZmAK2nYKqft AumbS/R3Si5I2E/pzUgl7dSPltWt1b9e1Hr81mQeyPeF9cdE1ooqTRTRGL3nhFsA7z 7GglN3YzpwLrw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/FKcTm7wHtf_VPg-CHpBukzk3sjk Subject: Re: [clue] CLUE agenda for IETF91 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, 30 Oct 2014 14:38:15 -0000 I just uploaded a revised agenda, addressing the comments I have received so far. It is still at: http://www.ietf.org/proceedings/91/agenda/agenda-91-clue Because some presenters have given back time, we seem to have a little extra. So I put in some time for call flows at the end. But unless something changes (new version, etc.) it still is an as-time-permits topic. If some of the other topics can use more time to speed completion then I'll be inclined to let them take it. Speakers (especially those who haven't yet commented) please consider again the amount of time you need. And comment if you think a reordering of topics would be helpful. Thanks, Paul From nobody Thu Oct 30 10:24:31 2014 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 4229F1A03A3 for ; Thu, 30 Oct 2014 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKj6mJQ1uIAk for ; Thu, 30 Oct 2014 10:24:26 -0700 (PDT) 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 0D2721A0395 for ; Thu, 30 Oct 2014 10:24:25 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-bb-54527447f0d0 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A3.B6.04387.74472545; Thu, 30 Oct 2014 18:24:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 18:24:23 +0100 From: Christer Holmberg To: 'Simon Pietro Romano' , Paul Kyzivat , CLUE Thread-Topic: [clue] CLUE agenda for IETF91 - CLUE data channel Thread-Index: Ac/0ZlpbRdqQx2JLTMW34Xll6qBWUA== Date: Thu, 30 Oct 2014 17:24:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D6739@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4D6739ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvja57SVCIQd8JA4v9py4zW6zYcIDV YlvbDWYHZo+/7z8weSxZ8pPJ48eWp0wBzFFcNimpOZllqUX6dglcGbduTmcu2NfGWHF74U6m BsYPTYxdjJwcEgImEu/nLISyxSQu3FvP1sXIxSEkcIRRYv/s1awgCSGBJUDOZ/kuRg4ONgEL ie5/2iBhEYFsiRXLprOD2MICdhI7965kBCkREbCX2LZYBaJET2LP3KlsIDaLgKrErj1PwMp5 BXwlnv7dDLaWEWjt91NrmEBsZgFxiVtP5jNBnCMgsWTPeWYIW1Ti5eN/rBC2ksTaw9tZIOrz JR7ee8MKMVNQ4uTMJywTGIVmIRk1C0nZLCRls4AuZRbQlFi/Sx+iRFFiSvdDdghbQ6J1zlx2 ZPEFjOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQIj5+CW31Y7GA8+dzzEKMDBqMTD++Fh YIgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA0VZ622s9z PmNP6pZ5vryL5ry5Vrtb4XzlhdTyNLNDk0TnxXct1zlTPE/UvOzIbXfvWws+sP2Q1j1S/TGV V1D/WsGpV1JqtvEHrMTCbv4v7+V6nTr9RDPbyZT0OlvBWQEb/Zb//XR07uKHQpr/jlZnft1m 8HRz3Mcc1sxv/WfYJFv9rBL0nPuUWIozEg21mIuKEwGXRvqefQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/nWxMuTiz90lhwxR3ctTRDizKm4U Subject: Re: [clue] CLUE agenda for IETF91 - CLUE data channel 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, 30 Oct 2014 17:24:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4D6739ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClJlZ2FyZGluZyB0aGUgZGF0YSBjaGFubmVsLCBJIHRoaW5rIHRoZXJlIGFyZSB0d28g dGVjaG5pY2FsIG9wZW4gaXNzdWVzOg0KDQoNCjEpICAgICAgQXJlIHdlIGdvaW5nIHRvIHVzZSBT SE9VTEQgZm9yIFNDVFAgaW50ZXJsZWF2aW5nLCBvciBhcmUgd2UgZ29pbmcgdG8gYWxsb3cgbm90 IHRvIHVzZSBpdCBhdCBhbGw/DQoNCg0KDQpUaGVyZSBhcmUgY3VycmVudGx5IG9uZ29pbmcgZGlz Y3Vzc2lvbnMgYWJvdXQgdGhpcyBpbiBib3RoIFJUQ1dFQiBhbmQgVFNWV0csIHNvIEkgZ3Vlc3Mg d2UgaGF2ZSB0byB3YWl0IGZvciB0aGUgb3V0Y29tZS4NCg0KDQoNCjIpICAgICAgQXJlIHdlIGdv aW5nIHRvIHVzZSDigJxSaWNoYXJk4oCZcyBkcmFmdOKAnSAoZHJhZnQtZWp6YWstbW11c2ljLWRh dGEtY2hhbm5lbC1zZHBuZWcpPw0KDQoNCg0KQXMgd2UgaGF2ZSBkaXNjdXNzZWQsIHdlIGFyZSBv cGVuIHRvIHVzZSBpdCwgaWYgaXQgcHJvZ3Jlc3Nlcy4gSSBndWVzcyBpdCByZWxhdGVzIG1vcmUg dG8gdGhlIENMVUUgc2lnbmFsaW5nIGRyYWZ0LCB0aG91Z2guDQoNClJlZ2FyZHMsDQoNCkNocmlz dGVyDQoNCg0KDQpGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU2ltb24gUGlldHJvIFJvbWFubw0KU2VudDogMzAuIGxva2FrdXV0YSAyMDE0IDk6 MzUNClRvOiBQYXVsIEt5eml2YXQ7IENMVUUNClN1YmplY3Q6IFJlOiBbY2x1ZV0gQ0xVRSBhZ2Vu ZGEgZm9yIElFVEY5MQ0KDQpIaSBQYXVsLA0KDQpJIHRoaW5rIHRoYXQgYSB0b3RhbCBvZiAxIGhv dXIgaXMgZW5vdWdoIGZvciBwcmVzZW50aW5nIGJvdGggdGhlIHByb3RvY29sIGFuZCB0aGUgZGF0 YSBtb2RlbCBkcmFmdHMuDQoNClNpbW9uDQpJbCAyOSBvdHRvYnJlIDIwMTQgMTk6NTE6MDQgQ0VU LCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1 bS5taXQuZWR1Pj4gaGEgc2NyaXR0bzoNCg0KWW91IGNhbiBmaW5kIGEgdmVyeSBwcmVsaW1pbmFy eSBhZ2VuZGEgZm9yIG91ciBDTFVFIHNlc3Npb25zIGF0IElFVEY5MToNCg0KICAgICBodHRwOi8v d3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL2FnZW5kYS9hZ2VuZGEtOTEtY2x1ZQ0KDQpJIHRy aWVkIHRvIHByaW9yaXRpemUgdGhvc2UgdGhpbmdzIHRoYXQgbmVlZCB0aGUgbW9zdCB3b3JrLCBh bmQgdGhhdA0KaGF2ZSBoYWQgcmVjZW50IGFjdGlvbi4NCg0KTm90ZSB0aGF0IGZvciBub3cgSSBn YXZlIG5vIHRpbWUgdG8gdGhlIGNhbGwgZmxvd3MsIGJlY2F1c2UgdGhlcmUgaGF2ZQ0KYmVlbiBu byBjaGFuZ2VzIHNpbmNlIHRoZSBsYXN0IG1lZXRpbmcuDQoNCkZvciB0aGUgUlRQIE1hcHBpbmcs IHdobyB3aWxsIGJlIGxlYWRpbmcgdGhlIGRpc2N1c3Npb24/IFJvbmkgb3IgSm9uYXRoYW4/DQoN CkkgcmVxdWVzdCB0aGF0IGFsbCBhdXRob3JzL3ByZXNlbnRlcnMgcGxlYXNlIHJldmlldyB0aGlz IGFuZCBjb25zaWRlcg0KaG93IG11Y2ggdGltZSB5b3UgY2FuIGVmZmVjdGl2ZWx5IHVzZS4gV2Ug ZG9uJ3QgaGF2ZSBlbm91Z2gNCmRpc2NyZXRpb25hcnkgdGltZSBmb3IgZm9sbG93dXAsIHNvIGlm IHlvdSBkb24ndCBuZWVkIGFzIG11Y2ggdGltZSBhcyBJDQphbGxvdHRlZCBwbGVhc2UgbGV0IG1l IGtub3cuDQoNCkFuZCBub3RlIHRoYXQgdGhlIGFnZW5kYSBuZWVkcyB0byBiZSBmaW5hbGl6ZWQg YnkgTW9uZGF5LCBzbyBJIG5lZWQgeW91cg0KZmVlZGJhY2sgYmVmb3JlIHRoZW4uDQoNCiAgICAg ICAgVGhhbmtzLA0KICAgICAgICBQYXVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCmNsdWUNCg0KDQoNCm1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZzxtYWlsdG86Y2x1 ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K --_000_7594FB04B1934943A5C02806D1A2204B1D4D6739ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4t bGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MjAyMDQyNTY5NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTExMTEwOTQ4NDQgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdp bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgdGhlIGRh dGEgY2hhbm5lbCwgSSB0aGluayB0aGVyZSBhcmUgdHdvIHRlY2huaWNhbCBvcGVuIGlzc3Vlczo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5B cmUgd2UgZ29pbmcgdG8gdXNlIFNIT1VMRCBmb3IgU0NUUCBpbnRlcmxlYXZpbmcsIG9yIGFyZSB3 ZSBnb2luZyB0byBhbGxvdyBub3QgdG8gdXNlIGl0IGF0IGFsbD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGVyZSBhcmUgY3VycmVudGx5IG9uZ29pbmcgZGlzY3Vzc2lvbnMgYWJvdXQgdGhp cyBpbiBib3RoIFJUQ1dFQiBhbmQgVFNWV0csIHNvIEkgZ3Vlc3Mgd2UgaGF2ZSB0byB3YWl0IGZv ciB0aGUgb3V0Y29tZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcmUgd2UgZ29pbmcgdG8gdXNlIOKAnFJpY2hhcmTigJlz IGRyYWZ04oCdIChkcmFmdC1lanphay1tbXVzaWMtZGF0YS1jaGFubmVsLXNkcG5lZyk/DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyB3ZSBoYXZlIGRpc2N1c3NlZCwgd2UgYXJlIG9wZW4g dG8gdXNlIGl0LCBpZiBpdCBwcm9ncmVzc2VzLiBJIGd1ZXNzIGl0IHJlbGF0ZXMgbW9yZSB0byB0 aGUgQ0xVRSBzaWduYWxpbmcgZHJhZnQsIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYu b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TaW1vbiBQaWV0cm8gUm9tYW5vPGJyPg0KPGI+U2Vu dDo8L2I+IDMwLiBsb2tha3V1dGEgMjAxNCA5OjM1PGJyPg0KPGI+VG86PC9iPiBQYXVsIEt5eml2 YXQ7IENMVUU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjbHVlXSBDTFVFIGFnZW5kYSBmb3Ig SUVURjkxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhp IFBhdWwsIDxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCBhIHRvdGFsIG9mIDEgaG91ciBpcyBlbm91 Z2ggZm9yIHByZXNlbnRpbmcgYm90aCB0aGUgcHJvdG9jb2wgYW5kIHRoZSBkYXRhIG1vZGVsIGRy YWZ0cy4NCjxicj4NCjxicj4NClNpbW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbCAyOSBvdHRvYnJlIDIwMTQg MTk6NTE6MDQgQ0VULCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpwa3l6aXZhdEBh bHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IGhhIHNjcml0dG86PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5Zb3UgY2FuIGZpbmQgYSB2ZXJ5IHByZWxpbWluYXJ5IGFnZW5kYSBm b3Igb3VyIENMVUUgc2Vzc2lvbnMgYXQgSUVURjkxOjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTEvYWdlbmRh L2FnZW5kYS05MS1jbHVlIj5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL2FnZW5k YS9hZ2VuZGEtOTEtY2x1ZTwvYT48YnI+PGJyPkkgdHJpZWQgdG8gcHJpb3JpdGl6ZSB0aG9zZSB0 aGluZ3MgdGhhdCBuZWVkIHRoZSBtb3N0IHdvcmssIGFuZCB0aGF0IDxicj5oYXZlIGhhZCByZWNl bnQgYWN0aW9uLjxicj48YnI+Tm90ZSB0aGF0IGZvciBub3cgSSBnYXZlIG5vIHRpbWUgdG8gdGhl IGNhbGwgZmxvd3MsIGJlY2F1c2UgdGhlcmUgaGF2ZSA8YnI+YmVlbiBubyBjaGFuZ2VzIHNpbmNl IHRoZSBsYXN0IG1lZXRpbmcuPGJyPjxicj5Gb3IgdGhlIFJUUCBNYXBwaW5nLCB3aG8gd2lsbCBi ZSBsZWFkaW5nIHRoZSBkaXNjdXNzaW9uPyBSb25pIG9yIEpvbmF0aGFuPzxicj48YnI+SSByZXF1 ZXN0IHRoYXQgYWxsIGF1dGhvcnMvcHJlc2VudGVycyBwbGVhc2UgcmV2aWV3IHRoaXMgYW5kIGNv bnNpZGVyIDxicj5ob3cgbXVjaCB0aW1lIHlvdSBjYW4gZWZmZWN0aXZlbHkgdXNlLiBXZSBkb24n dCBoYXZlIGVub3VnaCA8YnI+ZGlzY3JldGlvbmFyeSB0aW1lIGZvciBmb2xsb3d1cCwgc28gaWYg eW91IGRvbid0IG5lZWQgYXMgbXVjaCB0aW1lIGFzIEkgPGJyPmFsbG90dGVkIHBsZWFzZSBsZXQg bWUga25vdy48YnI+PGJyPkFuZCBub3RlIHRoYXQgdGhlIGFnZW5kYSBuZWVkcyB0byBiZSBmaW5h bGl6ZWQgYnkgTW9uZGF5LCBzbyBJIG5lZWQgeW91ciA8YnI+ZmVlZGJhY2sgYmVmb3JlIHRoZW4u PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhbmtz LDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGF1bDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFu IGxhbmc9IkVOLVVTIj48aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj5jbHVlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4gPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPm1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86Y2x1ZUBpZXRmLm9yZyI+Y2x1ZUBp ZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jbHVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWU8L2E+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4D6739ESESSMB209erics_-- From nobody Thu Oct 30 10:58:07 2014 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 340761A19FD for ; Thu, 30 Oct 2014 10:58:06 -0700 (PDT) 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 D2Vmvq1DhAyf for ; Thu, 30 Oct 2014 10:58:04 -0700 (PDT) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4391A01A8 for ; Thu, 30 Oct 2014 10:58:03 -0700 (PDT) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-11v.sys.comcast.net with comcast id 9Vx81p00C58ss0Y01Vy3eD; Thu, 30 Oct 2014 17:58:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-14v.sys.comcast.net with comcast id 9Vy21p00C3Ge9ey01Vy2Ma; Thu, 30 Oct 2014 17:58:03 +0000 Message-ID: <54527C2A.7020404@alum.mit.edu> Date: Thu, 30 Oct 2014 13:58:02 -0400 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: Christer Holmberg , 'Simon Pietro Romano' , CLUE References: <7594FB04B1934943A5C02806D1A2204B1D4D6739@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D6739@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414691883; bh=6SIgMIt7cV6lweMal56NT1AVBZtIeQ7T0gARn+Uuyl8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JpSiK6jmCta7b7YTJCf6p/XGT54nM9sit32sWkevMvRJivaMJMYcEoEtbo4naBikM wQdDHGu+0MpHDBq2KqR6OQ3El6JlDnpUPMAChGVvfwEQC+sDy1lECaR8LGSZvchyh3 OfgmuReRAcged+HfVHcb3PYW4BrGAIC85ZQqDxrHimB3K3i3LGiykDbUHSUEzsLgba WCjIKJrroJAUhhDx75GGPKEVvonFxEJcU4kDNGDdo99i0CrGmv+Jkm2t/U9ef0gGkF S2BzocaCmw0sPuYMwNxOJeeW/GxWH4KdVOALfevCVVrKnd++KFIQBEGK4CD3uaeh3g cS497EO/BHJaQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6BcyTQYz1BP60E58pNaAYEKe-js Subject: Re: [clue] CLUE agenda for IETF91 - CLUE data channel 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, 30 Oct 2014 17:58:06 -0000 On 10/30/14 1:24 PM, Christer Holmberg wrote: > Hi, > > Regarding the data channel, I think there are two technical open issues: > > 1)Are we going to use SHOULD for SCTP interleaving, or are we going to > allow not to use it at all? > > There are currently ongoing discussions about this in both RTCWEB and > TSVWG, so I guess we have to wait for the outcome. Since the discussion of data channels is on the agenda for Friday we will have the advantage of knowing whatever has happened on this during the week. > 2)Are we going to use “Richard’s draft” > (draft-ejzak-mmusic-data-channel-sdpneg)? > > As we have discussed, we are open to use it, if it progresses. I guess > it relates more to the CLUE signaling draft, though. Agree that is a signaling issue. I think we understand that it is a possibility if it gets done in time. But Mary and I agree that we shouldn't delay things to fit this in. What might be work discussing is what to do if it is done in time. Notably, would we require it to be signaled for CLUE, or would either way be valid? Thanks, Paul > Regards, > > Christer > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Simon Pietro > Romano > *Sent:* 30. lokakuuta 2014 9:35 > *To:* Paul Kyzivat; CLUE > *Subject:* Re: [clue] CLUE agenda for IETF91 > > Hi Paul, > > I think that a total of 1 hour is enough for presenting both the > protocol and the data model drafts. > > Simon > > Il 29 ottobre 2014 19:51:04 CET, Paul Kyzivat > ha scritto: > > You can find a very preliminary agenda for our CLUE sessions at IETF91: > > http://www.ietf.org/proceedings/91/agenda/agenda-91-clue > > I tried to prioritize those things that need the most work, and that > have had recent action. > > Note that for now I gave no time to the call flows, because there have > been no changes since the last meeting. > > For the RTP Mapping, who will be leading the discussion? Roni or Jonathan? > > I request that all authors/presenters please review this and consider > how much time you can effectively use. We don't have enough > discretionary time for followup, so if you don't need as much time as I > allotted please let me know. > > And note that the agenda needs to be finalized by Monday, so I need your > feedback before then. > > Thanks, > Paul > > ------------------------------------------------------------------------ > > > clue > > > > mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Oct 30 11:30:47 2014 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 1B1FF1A1A28 for ; Thu, 30 Oct 2014 11:30:42 -0700 (PDT) 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 33nGhjA8CGwj for ; Thu, 30 Oct 2014 11:30:39 -0700 (PDT) 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 296741A1A1E for ; Thu, 30 Oct 2014 11:30:38 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-62-545283cc5faf Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.A7.04231.CC382545; Thu, 30 Oct 2014 19:30:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 19:30:36 +0100 From: Christer Holmberg To: Paul Kyzivat , 'Simon Pietro Romano' , CLUE Thread-Topic: [clue] CLUE agenda for IETF91 - CLUE data channel Thread-Index: Ac/0ZlpbRdqQx2JLTMW34Xll6qBWUP//+KAA///pCYA= Date: Thu, 30 Oct 2014 18:30:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D6A7B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4D6739@ESESSMB209.ericsson.se> <54527C2A.7020404@alum.mit.edu> In-Reply-To: <54527C2A.7020404@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvje6Z5qAQgwWzzCz2n7rMbLFiwwFW i21tN5gdmD3+vv/A5LFkyU8mjx9bnjIFMEdx2aSk5mSWpRbp2yVwZdw5eJit4JxKxbFdvg2M V5S7GDk5JARMJJqazjFC2GISF+6tZ+ti5OIQEjjCKNF/cTMThLOEUeLn6d1AVRwcbAIWEt3/ tEFMEYFsieMbo0F6hQXsJHbuXckIEbaX2LZYBSQsImAl0XRgMjOIzSKgKrH3wF82kBJeAV+J p2tyQMJCAvkSR19OAruAU0BH4sP9O2A2I9A130+tYQKxmQXEJW49mc8EcaWAxJI955khbFGJ l4//sULYShJrD29nARnPLKApsX6XPkSrosSU7ofsIDavgKDEyZlPWCYwis5CMnUWQscsJB2z kHQsYGRZxShanFpcnJtuZKyXWpSZXFycn6eXl1qyiREYLwe3/Nbdwbj6teMhRgEORiUe3g8P A0OEWBPLiitzDzFKc7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjbvteqyrb x7ICrjvnFcp/l3vEpPSq56ziUYZTu33m3d6Xt9IzOozf6JoOg5Ja5rwrdmfm1gUzGP799c+b /7zqqt93nJxMpSPPCQtcFt41M3PrDZWav16/k/ff6xd+KTN/71WZwrr388Lum345FlASu9Fs oyynmPZJs7vh8U2V5ua3A+/kapgosRRnJBpqMRcVJwIAlVSJfXgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Cpw2-aRAp0tn2bDr7sH_i3fYHro Subject: Re: [clue] CLUE agenda for IETF91 - CLUE data channel 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, 30 Oct 2014 18:30:42 -0000 SGksDQoNCj4+IFJlZ2FyZGluZyB0aGUgZGF0YSBjaGFubmVsLCBJIHRoaW5rIHRoZXJlIGFyZSB0 d28gdGVjaG5pY2FsIG9wZW4gaXNzdWVzOg0KPj4NCj4+IDEpQXJlIHdlIGdvaW5nIHRvIHVzZSBT SE9VTEQgZm9yIFNDVFAgaW50ZXJsZWF2aW5nLCBvciBhcmUgd2UgZ29pbmcgdG8gDQo+PiBhbGxv dyBub3QgdG8gdXNlIGl0IGF0IGFsbD8NCj4+DQo+PiBUaGVyZSBhcmUgY3VycmVudGx5IG9uZ29p bmcgZGlzY3Vzc2lvbnMgYWJvdXQgdGhpcyBpbiBib3RoIFJUQ1dFQiBhbmQgDQo+PiBUU1ZXRywg c28gSSBndWVzcyB3ZSBoYXZlIHRvIHdhaXQgZm9yIHRoZSBvdXRjb21lLg0KPg0KPiBTaW5jZSB0 aGUgZGlzY3Vzc2lvbiBvZiBkYXRhIGNoYW5uZWxzIGlzIG9uIHRoZSBhZ2VuZGEgZm9yIEZyaWRh eSB3ZSB3aWxsIGhhdmUgdGhlIGFkdmFudGFnZSA+IG9mIGtub3dpbmcgd2hhdGV2ZXIgaGFzIGhh cHBlbmVkIG9uIHRoaXMgZHVyaW5nIHRoZSB3ZWVrLg0KDQpMZXQncyBob3BlIHNvLiBCdXQsIEkg d2FzIHRvbGQgdGhhdCBNaWNoYWVsIFR1ZXhlbiB3aWxsIG5vdCBhdHRlbmQgdGhlIEhhd2FpaSBt ZWV0aW5nLCBzby4uLiANCg0KPj4gMilBcmUgd2UgZ29pbmcgdG8gdXNlIOKAnFJpY2hhcmTigJlz IGRyYWZ04oCdDQo+PiAoZHJhZnQtZWp6YWstbW11c2ljLWRhdGEtY2hhbm5lbC1zZHBuZWcpPw0K Pj4NCj4+IEFzIHdlIGhhdmUgZGlzY3Vzc2VkLCB3ZSBhcmUgb3BlbiB0byB1c2UgaXQsIGlmIGl0 IHByb2dyZXNzZXMuIEkgZ3Vlc3MgDQo+PiBpdCByZWxhdGVzIG1vcmUgdG8gdGhlIENMVUUgc2ln bmFsaW5nIGRyYWZ0LCB0aG91Z2guDQo+DQo+IEFncmVlIHRoYXQgaXMgYSBzaWduYWxpbmcgaXNz dWUuIEkgdGhpbmsgd2UgdW5kZXJzdGFuZCB0aGF0IGl0IGlzIGEgcG9zc2liaWxpdHkgaWYgaXQg Z2V0cyBkb25lIGluIA0KPiB0aW1lLiBCdXQgTWFyeSBhbmQgSSBhZ3JlZSB0aGF0IHdlIHNob3Vs ZG4ndCBkZWxheSB0aGluZ3MgdG8gZml0IHRoaXMgaW4uDQoNCkVhcmxpZXIgdG9kYXkgSSBjaGVj a2VkIHRoZSBNTVVTSUMsIGFuZCB0aGUgZHJhZnQgd2Fzbid0IHRoZXJlLiBCdXQsIEkgaGVhcmQg dGhhdCB0aGUgY2hhaXJzIGhhdmUgcmVjZWl2ZWQgYSByZXF1ZXN0IGZvciBhZ2VuZGEgdGltZSwg c28gbGV0J3Mgc2VlIHdoYXQgaGFwcGVucy4NCg0KPldoYXQgbWlnaHQgYmUgd29yayBkaXNjdXNz aW5nIGlzIHdoYXQgdG8gZG8gaWYgaXQgaXMgZG9uZSBpbiB0aW1lLiANCj5Ob3RhYmx5LCB3b3Vs ZCB3ZSByZXF1aXJlIGl0IHRvIGJlIHNpZ25hbGVkIGZvciBDTFVFLCBvciB3b3VsZCBlaXRoZXIg d2F5IGJlIHZhbGlkPw0KDQpJIGd1ZXNzIHdlIHdpbGwgQU5ZV0FZIG5lZWQgdGhlIENMVUUgZ3Jv dXBpbmcgYXR0cmlidXRlIHZhbHVlLCBzaW5jZSB3ZSBuZWVkIHRvIGdyb3VwIHRoZSBDTFVFIGF1 ZGlvLSBhbmQgdmlkZW8gbS0gbGluZXMuIFNvLCB3ZSBDQU4gdXNlIGl0IHRvIGluZGljYXRlIHRo YXQgdGhlIGRhdGEgY2hhbm5lbCBpcyB1c2VkIGZvciBDTFVFLg0KDQpCdXQsIEkgc3RpbGwgdGhp bmsgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIGEgZ2VuZXJhbCB3YXkgZm9yIG5lZ290aWF0aW5n IHRoZSBkYXRhIGNoYW5uZWwgdXNhZ2VzLiBFc3BlY2lhbGx5IGlmIHNvbWVvbmUgYWxzbyB3YW50 cyB0byB1c2UgdGhlIGRhdGEgY2hhbm5lbCBmb3Igc29tZXRoaW5nIGVsc2UgdGhhbiBDTFVFLCBJ IHRoaW5rIGl0IGlzIGJhZCB0byBoYXZlIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciBuZWdvdGlh dGluZyB0aGUgdXNhZ2UuDQoNCkhhdmluZyBzYWlkIHRoYXQsIE5PVCBoYXZpbmcgc3VjaCBtZWNo YW5pc20gc2hvdWxkIG9mIGNvdXJzZSBub3QgaG9sZCBDTFVFIGhvc3RhZ2UuIA0KDQpSZWdhcmRz LA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo+ICpGcm9tOipjbHVlIFttYWlsdG86Y2x1ZS1ib3VuY2Vz QGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpTaW1vbiBQaWV0cm8gDQo+IFJvbWFubw0KPiAqU2Vu dDoqIDMwLiBsb2tha3V1dGEgMjAxNCA5OjM1DQo+ICpUbzoqIFBhdWwgS3l6aXZhdDsgQ0xVRQ0K PiAqU3ViamVjdDoqIFJlOiBbY2x1ZV0gQ0xVRSBhZ2VuZGEgZm9yIElFVEY5MQ0KPg0KPiBIaSBQ YXVsLA0KPg0KPiBJIHRoaW5rIHRoYXQgYSB0b3RhbCBvZiAxIGhvdXIgaXMgZW5vdWdoIGZvciBw cmVzZW50aW5nIGJvdGggdGhlIA0KPiBwcm90b2NvbCBhbmQgdGhlIGRhdGEgbW9kZWwgZHJhZnRz Lg0KPg0KPiBTaW1vbg0KPg0KPiBJbCAyOSBvdHRvYnJlIDIwMTQgMTk6NTE6MDQgQ0VULCBQYXVs IEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdSANCj4gPG1haWx0bzpwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+PiBoYSBzY3JpdHRvOg0KPg0KPiBZb3UgY2FuIGZpbmQgYSB2ZXJ5IHByZWxpbWlu YXJ5IGFnZW5kYSBmb3Igb3VyIENMVUUgc2Vzc2lvbnMgYXQgSUVURjkxOg0KPg0KPiAgICAgICBo dHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL2FnZW5kYS9hZ2VuZGEtOTEtY2x1ZQ0K Pg0KPiBJIHRyaWVkIHRvIHByaW9yaXRpemUgdGhvc2UgdGhpbmdzIHRoYXQgbmVlZCB0aGUgbW9z dCB3b3JrLCBhbmQgdGhhdCANCj4gaGF2ZSBoYWQgcmVjZW50IGFjdGlvbi4NCj4NCj4gTm90ZSB0 aGF0IGZvciBub3cgSSBnYXZlIG5vIHRpbWUgdG8gdGhlIGNhbGwgZmxvd3MsIGJlY2F1c2UgdGhl cmUgaGF2ZSANCj4gYmVlbiBubyBjaGFuZ2VzIHNpbmNlIHRoZSBsYXN0IG1lZXRpbmcuDQo+DQo+ IEZvciB0aGUgUlRQIE1hcHBpbmcsIHdobyB3aWxsIGJlIGxlYWRpbmcgdGhlIGRpc2N1c3Npb24/ IFJvbmkgb3IgSm9uYXRoYW4/DQo+DQo+IEkgcmVxdWVzdCB0aGF0IGFsbCBhdXRob3JzL3ByZXNl bnRlcnMgcGxlYXNlIHJldmlldyB0aGlzIGFuZCBjb25zaWRlciANCj4gaG93IG11Y2ggdGltZSB5 b3UgY2FuIGVmZmVjdGl2ZWx5IHVzZS4gV2UgZG9uJ3QgaGF2ZSBlbm91Z2ggDQo+IGRpc2NyZXRp b25hcnkgdGltZSBmb3IgZm9sbG93dXAsIHNvIGlmIHlvdSBkb24ndCBuZWVkIGFzIG11Y2ggdGlt ZSBhcyANCj4gSSBhbGxvdHRlZCBwbGVhc2UgbGV0IG1lIGtub3cuDQo+DQo+IEFuZCBub3RlIHRo YXQgdGhlIGFnZW5kYSBuZWVkcyB0byBiZSBmaW5hbGl6ZWQgYnkgTW9uZGF5LCBzbyBJIG5lZWQg DQo+IHlvdXIgZmVlZGJhY2sgYmVmb3JlIHRoZW4uDQo+DQo+ICAgICAgICAgIFRoYW5rcywNCj4g ICAgICAgICAgUGF1bA0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+DQo+DQo+IGNsdWUNCj4N Cj4NCj4NCj4gbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcgIDxtYWlsdG86Y2x1ZUBpZXRm Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+DQoN Cg== From nobody Thu Oct 30 17:04:16 2014 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 1AD031A896B for ; Thu, 30 Oct 2014 17:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.67 X-Spam-Level: ** X-Spam-Status: No, score=2.67 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 jyU2ENcOYFJ5 for ; Thu, 30 Oct 2014 17:04:12 -0700 (PDT) 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 8187C1A8952 for ; Thu, 30 Oct 2014 17:04:08 -0700 (PDT) X-ASG-Debug-ID: 1414713846-05ce3723b6707860001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id G4eTLA5sxbUsuAxF (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2014 01:04:06 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.1.102] ([94.161.69.212]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id s9V04447022176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 Oct 2014 01:04:05 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_D51FDCB2-5C77-489A-8C15-4976C2EB817C" Message-Id: <1545E39E-7A43-4822-96B4-023666F01F40@unina.it> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Fri, 31 Oct 2014 01:04:04 +0100 X-ASG-Orig-Subj: Re: [clue] Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" References: <54512FEB.5010603@alum.mit.edu> To: Paul Kyzivat , clue@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1414713846 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.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.11061 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: http://mailarchive.ietf.org/arch/msg/clue/UjvfVIU9zv7xAO0VOkolSGVYncI Subject: Re: [clue] Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 31 Oct 2014 00:04:15 -0000 --Apple-Mail=_D51FDCB2-5C77-489A-8C15-4976C2EB817C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello everybody, I am awfully sorry, but I'm not able to find a large-enough slot to = allocate to the whiteboarding session in Honolulu. I'll be busy all the = time with Meetecho remote participation support. I'm afraid we'll have to postpone such a session. Roberta and I will = certainly be available starting from the first week after the meeting. Cheers, Simon On 30/ott/2014, at 08:51, Simon Pietro Romano wrote: > Hi Paul,=20 >=20 > I'm the only one who will be in Honolulu. Unfortunately Roberta could = not make it :-(. I'm trying to figure out how to take enough time out of = the Meetecho schedule in order to participate in the 'whiteboarding' = meeting. By today EOB I'll fill in the poll. >=20 > Simon >=20 > Il 29 ottobre 2014 19:20:27 CET, Paul Kyzivat = ha scritto: > So far we have Mary and I, Roni and Christer. And there is only one = slot=20 > that isn't a NO for anyone. But we don't have Simon/Roberta. Without = one=20 > of them there is probably no point. >=20 > Roberta - will you be in Honolulu? > Or is Simon reserving the *good* trips for himself? :-) >=20 > Thanks, > Paul >=20 > On 10/28/14 1:02 PM, Mary Barnes wrote: >=20 > You have initiated a poll "CLUE Design Team - Protocol whiteboarding" = at > Doodle. The link to your poll is: >=20 > http://doodle.com/cxz9u66a545x7f7r >=20 > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have = used > your e-mail address; simply ignore this e-mail, > =20 > =20 > please.) >=20 >=20 > 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 _\\|//_ ( 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=_D51FDCB2-5C77-489A-8C15-4976C2EB817C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = everybody,

I am awfully sorry, but I'm not able to = find a large-enough slot to allocate to the whiteboarding session in = Honolulu. I'll be busy all the time with Meetecho remote participation = support.
I'm afraid we'll have to postpone such a session. = Roberta and I will certainly be available starting from the first week = after the = meeting.

Cheers,

Simon


On 30/ott/2014, at 08:51, Simon = Pietro Romano <spromano@unina.it> = wrote:

Hi Paul,

I'm the only one who will be in Honolulu. Unfortunately Roberta could = not make it :-(. I'm trying to figure out how to take enough time out of = the Meetecho schedule in order to participate in the 'whiteboarding' = meeting. By today EOB I'll fill in the poll.

Simon

Il 29 ottobre 2014 19:20:27 CET, = Paul Kyzivat <pkyzivat@alum.mit.edu> ha = scritto:
So far we have Mary and I, Roni and Christer. And =
there is only one slot 
that isn't a NO for anyone. But we don't have =
Simon/Roberta. Without one 
of them there is probably no =
point.

Roberta - will you be in Honolulu?
Or is Simon =
reserving the *good* trips for himself? :-)

	Thanks,
	=
Paul

On 10/28/14 1:02 PM, Mary Barnes wrote:

 You have initiated a poll "CLUE =
Design Team - Protocol whiteboarding" at
 Doodle. The link to your =
poll is:

 http://doodle.com/cxz9u66a545x=
7f7r

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


clue mailing list
clue@ietf.org
https://www.ietf.org/m=
ailman/listinfo/clue

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

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

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






= --Apple-Mail=_D51FDCB2-5C77-489A-8C15-4976C2EB817C-- From nobody Fri Oct 31 05:51:54 2014 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 44F0C1A8A82 for ; Fri, 31 Oct 2014 05:51:51 -0700 (PDT) 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 yt8cV2Pyr8-U for ; Fri, 31 Oct 2014 05:51:48 -0700 (PDT) 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 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A446B1A887C for ; Fri, 31 Oct 2014 05:51:47 -0700 (PDT) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-09v.sys.comcast.net with comcast id 9opZ1p00756HXL001orm1c; Fri, 31 Oct 2014 12:51:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id 9orl1p00N3Ge9ey01ormEG; Fri, 31 Oct 2014 12:51:46 +0000 Message-ID: <545385E1.4000704@alum.mit.edu> Date: Fri, 31 Oct 2014 08:51:45 -0400 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: Simon Pietro Romano , clue@ietf.org References: <54512FEB.5010603@alum.mit.edu> <1545E39E-7A43-4822-96B4-023666F01F40@unina.it> In-Reply-To: <1545E39E-7A43-4822-96B4-023666F01F40@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1414759906; bh=q0oTgnZ53YrGZST8k8FvfC4ZEcPCo5FU20r+Wki6YKU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wU4wP9sSvqS4+HyfMAcgOb12atSSLJV6vA+4uUr56AgD9wHv77odRXBgCT7cUMz8l qA9ldXmsG5QzdO4wSFEOVFfJBbrgDgW8Fwb/Jzujyw15YD77bdT2HY3G/NnCcgA3re /Em77TEY/mtzsgx1REro4OFGIKaiVOb035CQPG4SdqqiygpJyt5uYcDX9D1W4dinPh srTctxDDFODUy1rMwlIhmiWJ+UwfY+Pe/lkId77yGRYMp5LwOPzw0xNgNLICi8fjkL EukQH91/qYgto3TYaLMTJi84S9qbkWflcTJ9lxBANskLKAO1K4FjF37ZtmC/+UFpqx pgpNsl56/ftPg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/6D64SwRic1wmfHofhyAOOvOy_lA Subject: Re: [clue] Doodle: Link for poll "CLUE Design Team - Protocol whiteboarding" 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, 31 Oct 2014 12:51:51 -0000 On 10/30/14 8:04 PM, Simon Pietro Romano wrote: > Hello everybody, > > I am awfully sorry, but I'm not able to find a large-enough slot to > allocate to the whiteboarding session in Honolulu. I'll be busy all the > time with Meetecho remote participation support. > I'm afraid we'll have to postpone such a session. Roberta and I will > certainly be available starting from the first week after the meeting. OK. Unfortunate, but I understand. It was worth a try. This makes it more important that everyone do their homework by reviewing the state machines *in detail* before the meeting and being prepared to discuss any concerns concisely. Thanks, Paul > Cheers, > > Simon > > > On 30/ott/2014, at 08:51, Simon Pietro Romano > wrote: > >> Hi Paul, >> >> I'm the only one who will be in Honolulu. Unfortunately Roberta could >> not make it :-(. I'm trying to figure out how to take enough time out >> of the Meetecho schedule in order to participate in the >> 'whiteboarding' meeting. By today EOB I'll fill in the poll. >> >> Simon >> >> Il 29 ottobre 2014 19:20:27 CET, Paul Kyzivat > > ha scritto: >> >> So far we have Mary and I, Roni and Christer. And there is only one slot >> that isn't a NO for anyone. But we don't have Simon/Roberta. Without one >> of them there is probably no point. >> >> Roberta - will you be in Honolulu? >> Or is Simon reserving the *good* trips for himself? :-) >> >> Thanks, >> Paul >> >> On 10/28/14 1:02 PM, Mary Barnes wrote: >> >> You have initiated a poll "CLUE Design Team - Protocol >> whiteboarding" at >> Doodle. The link to your poll is: >> >> http://doodle.com/cxz9u66a545x7f7r >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally >> have used >> your e-mail address; simply ignore this e-mail, please.) >> >> >> ------------------------------------------------------------------------ >> >> 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 > > _\\|//_ > ( 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~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > >