From nobody Sun Jan 3 18:44:23 2016 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 EEF151B2A0E; Sun, 3 Jan 2016 18:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=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 7_halwxvTg-q; Sun, 3 Jan 2016 18:44:20 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 BFD1E1B2A0D; Sun, 3 Jan 2016 18:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=ZCnxsd/K82z8ZYW+R9syWnvm+mfIRVqnNbrKTSdOwYU=; b=NKmEz+lOV4tfFjWZbF2N84tajW bdEC7ZnpBd0f/9oqMsX7fVvroV6QdVW6mamsxfKiQn++ncLjsrLHvaTxrYvOyWBSghFk122B1XyJW pIa5y+A6nLrOW12DcDxjmpya/KIEir6HgQ+/BbeD11L+cuLSplwcg7528FZdwJIB51LDz3PF+1LNB 2PQbMNZH5ItasP7MbyjIIpNeraGMaOQnYkCSkb9kSEGXgraeF35LFA03mhOdem/ELfG3yUwe+3v2h HStUbRaQq6ALcPdoD22Rh0TKg6f81iB5o+jy2R8VOmwaPYXMqaB8RhuNCjudmbryJ3C+Dvv5WQ7qf fqXqE9ew==; Received: from ppp118-209-204-171.lns20.mel8.internode.on.net ([118.209.204.171]:51285 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aFv7x-000GMu-IN; Mon, 04 Jan 2016 13:44:09 +1100 To: Ben Campbell References: <20151215225655.19408.56476.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F3AB@CRPMBOXPRD08.polycom.com> <5679DA62.4020408@nteczone.com> From: Christian Groves Message-ID: <5689DC77.40507@nteczone.com> Date: Mon, 4 Jan 2016 13:44:07 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.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: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: "draft-ietf-clue-framework@ietf.org" , "clue@ietf.org" , "clue-chairs@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Yes on draft-ietf-clue-framework-24: (with COMMENT) 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, 04 Jan 2016 02:44:22 -0000 Hello Ben, Please see my replies below. Regards, Christian On 25/12/2015 9:53 AM, Ben Campbell wrote: > Hi, A couple more comments below: > > Thanks! > > Ben. > > > On 22 Dec 2015, at 17:18, Christian Groves wrote: > >> Hello Mark, >> >> Some comments below on your replies. >> >> Regards, >> Christian >> >> On 23/12/2015 5:16 AM, Duckworth, Mark wrote: >>> Hello Ben, >>> Thanks for the feedback. >>> I have a few more responses to your comments below. >>> Mark >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Tuesday, December 15, 2015 5:57 PM >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> I have some minor comments. These should be easy to resolve, and I >>>> don't >>>> think any are show-stoppers. >>>> >>>> === Subtantive === >>>> >>>> - Section 3, MCU definition. >>>> Does this need a normative reference to 4353? I'm not sure the >>>> definition >>>> can be understood as written without reading it. >>> [Duckworth, Mark] I don't know. Is there any objection to making >>> RFC4353 a normative reference? >> [CNG] I'm not sure its appropriate. The definition says >> "RFC4353-like" (doesn't sound particularly normative) and says then >> indicates that the MCU is without a RFC4353. Again its not >> normatively saying to use it. Just because the reference is >> information doesn't mean a person shouldn't read it if they're >> unfamiliar with it. > > It goes on to say "without the [RFC4353] requirement". > > The criteria for a normative reference is one that is required to > fully implement or understand the draft. I agree this one is > borderline. If you think someone can understand the MCU definition > without it well enough for the purposes of the document, then I won't > push on it. [CNG] I think the way MCU is used in CLUE the definition is sufficient. The MCU is simply one class of device that may use CLUE. > > [...] > >> >>>> -6, third bullet: >>>> It seems kind of odd to use a MUST for this, given that the >>>> criteria of >>>> professionally installed is somewhat vague. I think a non-normative >>>> recommendation would make more sense. >>> [Duckworth, Mark] It does seem odd. I think the working group >>> previously discussed this and decided on using MUST. >> [CNG] The MUST relates to systems that know their physical dimensions >> providing them in an Advertisement rather than relating to >> professionally installed systems. We could strike the "(for example >> professionally installed Telepresence room systems)" if that's >> causing a problem. > > Please see my related comment to Mark. > > [...] > >>> >>>> -15, paragaph 4: "DTLS/SRTP MUST be supported and SHOULD be used >>>> unless >>>> the media, which is based on RTP, is secured by other means..." >>>> Is "secured by other means" intended to be the sole exception? If so, >>>> then this might should say MUST ... unless". As defined in 2119, a >>>> SHOULD >>>> would allow an implementation to skip the protection for other >>>> reasons, >>>> if the implementer was aware of the implications, etc... >>>> Also, should the references to 7201 and 7202 be normative? >>> [Duckworth, Mark] I don't know. Does anybody else have a suggestion >>> about this? >> [CNG] I think the wording around this was discussed for awhile and >> what's in the framework was the compromise we came up with, i.e. "Its >> a really good idea to secure the media using SRTP-DTLS, but we can't >> force you if you have a reason not to". > > "If you have a good reason not to" is substantially different than "if > you are secured by other means". [CNG] Yes, true. Of course one of the reasons could be "if you are secured by other means". I think the main case that was considered was two endpoints operating inside one companies network. People felt the same level of security may not be needed as the wider internet. > > > From nobody Sun Jan 3 18:50:40 2016 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 E661D1B2A19 for ; Sun, 3 Jan 2016 18:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=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 jC1uEGii7pjI for ; Sun, 3 Jan 2016 18:50:37 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 1EA5A1B2A17 for ; Sun, 3 Jan 2016 18:50:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=Uc385rNJvy4xPdtnqXVgPp7/lQFPvlM0fWjv0Phgg1I=; b=ikBHsz6ghFhIjvfvtpHjUvCuGv j3/jwp2zhOjT8fRDh374npl1V5S76VMHnJ8MGbsMd5lLpgq1o/F66JhNpcufMAm27XtDKFKcoNNul rJTUGX/6eRoxg2Btwdx32oWy03wxRxBYYBTYi9Nr9EKypDfUR4G/lkrsTPXIuDgkkL+hSEBpgkddF kN0XG1ngLrpjD2NOVBu3bLcOuUoiH6kav3zRx0w8us7AX8JtB39annX3rz7ipyaPmsGADF3W8dL5k SivSFzEa1n5Ww7FfkW/XxcYQ/PDwq0gePIRMMB0UyqaX+364hoBLtw/wFx1+j/MDkWU1azxGvn9lE JOMybEaw==; Received: from ppp118-209-204-171.lns20.mel8.internode.on.net ([118.209.204.171]:51289 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aFvEB-000Gf1-CP for clue@ietf.org; Mon, 04 Jan 2016 13:50:35 +1100 To: clue@ietf.org References: <20151217125527.4771.42784.idtracker@ietfa.amsl.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172B8F414@CRPMBOXPRD08.polycom.com> <5679E379.1040306@cs.tcd.ie> <567A76AF.404@cs.tcd.ie> From: Christian Groves Message-ID: <5689DDF9.8090903@nteczone.com> Date: Mon, 4 Jan 2016 13:50:33 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.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: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT) 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, 04 Jan 2016 02:50:39 -0000 Hello, +1 on Stephan W's response. I also think this is a policy issue rather=20 than a protocol issue. Regards, Christian On 24/12/2015 5:09 AM, Stephan Wenger wrote: > Hi Stephen, all, > Pruning the distribution list, as this appears to be a post facto discu= ssion with respect to the framework document, and I don=E2=80=99t want to= waste the bandwidth of the IESG folks. > > > > > On 12/23/15, 02:25, "Stephen Farrell" wrote= : > >> Hi all, >> >> On 23/12/15 03:04, Stephan Wenger wrote: >>> I do not believe there is any value in documenting the above choices.= >>> The options are known and understood in the industry at large, and by= >>> reasonably competent people. >> I'll just note that the industry at large has IMO not yet done >> a good job on privacy, with e.g. user agents automatically >> re-sending data every time, once the data was entered or >> approved for sending once. (Yes, doing better has UI implications, >> but that's just a part of doing a good job.) >> >> And I consider the pushback from the authors here as a part of >> that - we need to get better at really considering privacy and >> at not just assuming that sending more data might be useful >> sometime and hence ought be done, just-in-case. >> >> In this case, I can imagine they may be tricky privacy issues >> to be considered as people join and leave calls. E.g. would >> Stephan's enterprise admin like all their employees to include >> job titles and business unit information in a call that involves >> outsiders? What if an outsider joins in the middle? And the same >> issues can come up where real privacy (a human and not corporate >> concept:-) is at issue, if I'm on a call with people with whom >> I'm happy to share location information and then a newcomer >> joins, what should I (or others) tell them? I think there may be >> real protocol design issues there as well as implementation >> issues. > No, I don=E2=80=99t think there is a "real protocol design issue=E2=80=9D= =2E There are certainly policy issues. Depending on your viewpoint re p= rivacy vs. usability (on which we obviously have different opinions), the= re may be implementation issues. But I doubt there are protocol issues. = And, for the framework, there is no issue at all. > > Let me explain by starting with the last statement. As I mentioned ear= lier (although in a different context), the relevant part of the framewor= k defines a data structure, but not how that data structure is populated,= except in a handful of cases (like the co-planar points in the area of c= apture), none of which appear to have privacy issues. The xCard attribut= e is optional, and within the xCard spec, all fields are optional but the= real name IIRC. Unless you want to enforce a privacy policy by data str= ucture design, there is no point to normatively specify anything here bey= ond hwat is already specified. We can (and now have) drawn special atte= ntion to the Xcard in the framework doc, and we do that even more so in t= he data model doc (which fleshes out the details of the data structures. = The security consideration section of the data model doc already mention= s initial requirements resulting from the potential use of xCard, though = those are not fully fleshed out yet (so please don=E2=80=99t beat up Robe= rta and Simon just now :-). I=E2=80=99m sure the current discussion will= lead to an improvement there, which is in part why I continue to beat up= this dead horse. > =20 > > As far as the protocol goes, I don=E2=80=99t think there are protocol d= esign issues. It=E2=80=99s absolutely supported by the current design th= at a room full of anonymous alcoholics joins an existing intra-enterprise= call, and does not send their xCard info, nor receives the xCards from t= he other rooms. All advertisements are sent point-to-point (no multicast= distribution), and all can be hand-tailored to fulfill the needs of the = respective recipients. Nowhere it is stated that all attributes in all a= dvertisements sent to all endpoints have to be all the same. So the prot= ocol should not have a =E2=80=9Creal protocol design issue=E2=80=9D with = respect to xCards, right? > > Stephan > >> But, none of this is blocking now so by all means go ahead but I >> do think we are missing a good opportunity to provide guidance >> here in a framework document that might cause those writing >> protocol specifications and implementations to stop and think >> about privacy when they otherwise might not. >> >> S. >> >> PS: None of the above is meant to imply that we're bad at >> privacy for nefarious reasons - I mostly do not think that is >> the case, it's just a thing we need to get better at. >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 4 13:40:40 2016 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 DD8891AC3CE for ; Mon, 4 Jan 2016 13:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 I5ABObJSOZy3 for ; Mon, 4 Jan 2016 13:40:37 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75D21AC3CD for ; Mon, 4 Jan 2016 13:40:35 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with comcast id 1xfH1s0032S2Q5R01xgbXg; Mon, 04 Jan 2016 21:40:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id 1xgZ1s00T3KdFy101xgauP; Mon, 04 Jan 2016 21:40:34 +0000 To: "Duckworth, Mark" , Roni Even , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@CRPMBOXPRD08.polycom.com> From: Paul Kyzivat Message-ID: <568AE6D0.6000503@alum.mit.edu> Date: Mon, 4 Jan 2016 16:40:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1451943635; bh=PzIM0IwVC8eoqcMEUvkf1kKyMNuWej7VnLZ9L7MfZT0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=T4eFUBVPcbGGBbLTl5LkTali2+V4JzAIoUcQFk/1KFr/PIuCmFPFAD0jz52Cypcgc En77ZC+qxVyLd9t37RnJh6hKZksdiEcadAmO1JdbTJZwi1xeIzUD5k6URJXKPI+9+1 wul4RCP9AqC3G7JZNWy0qzUB8FjaPk4KVkuLGkS33dUeSWyaRY76e305c4Q5Ij/HOv ncYBtzZOgAeqmBT5oDB2HGVe/f+k41Z2XwKm03JJX9Pywn1ohoOCR0mBYMWFrDIirA jzo/4plEvPfkoS3KHdiPb0pwtYPuYAIiPupAaLLcrHR7jJPVFg0Let+EVGJb0icjpT Lhk0NPbU6Boug== Archived-At: Subject: Re: [clue] Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 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, 04 Jan 2016 21:40:39 -0000 These sound like good observations. I have nothing to add. Thanks, Paul On 12/16/15 4:15 PM, Duckworth, Mark wrote: > Hi, > > Section 4, why did maxCaptureType change from unsignedInt to > positiveInteger? I thought we agreed not to use the unbounded integer > types. Is it just to disallow the value zero? Is there another way to do > that without allowing unbounded values? > > I had a few comments way back on draft 07 > , some > of which didn’t seem to be addressed. I think they are still worthwhile > considering, so I include them again here. > > Section 17 example > > “... endpoint-style Media Provider’s offer”. I think it should be “... > endpoint-style Media Provider’s advertisement” > > Section 17 p 48 simultaneous sets – I think it makes more sense to say > you can’t provide the loudest segment at same time as the zoomed out > view, because they would be using the same camera at different zoom > levels in this example. So VC3 and VC4 can’t be simultaneous. So then > SS2 should be just (VC0, VC2, VC4). > > The spatial information in the sample file doesn’t make sense, it looks > like just a placeholder because it is identical for all captures. I have > this proposal for spatial information. > > AC0 > > > > 0.0 > > 0.0 > > 10.0 > > > > 0.0 > > 1.0 > > 10.0 > > > > > > VC0 - left > > > > -2.0 > > 0.0 > > 10.0 > > > > > > -3.0 20.0 9.0 > > -1.0 20.0 9.0 > > -3.0 20.0 11.0 > > -1.0 20.0 11.0 > > > > VC1 - center > > > > 0.0 > > 0.0 > > 10.0 > > > > > > -1.0 20.0 9.0 > > 1.0 20.0 9.0 > > -1.0 20.0 11.0 > > 1.0 20.0 11.0 > > > > VC2 - right > > > > 2.0 > > 0.0 > > 10.0 > > > > > > 1.0 20.0 9.0 > > 3.0 20.0 9.0 > > 1.0 20.0 11.0 > > 3.0 20.0 11.0 > > > > VC3 - loudest segment > > > > -3.0 20.0 9.0 > > 3.0 20.0 9.0 > > -3.0 20.0 11.0 > > 3.0 20.0 11.0 > > > > VC4 - zoomed out > > > > 0.0 > > 0.0 > > 10.0 > > > > > > -3.0 20.0 7.0 > > 3.0 20.0 7.0 > > -3.0 20.0 13.0 > > 3.0 20.0 13.0 > > > > I suggest VC3 should have spatial information, rather than > true, because the framework says “For a switched > Capture that switches between different sections within a larger area, > the area of capture MUST use coordinates for the larger potential area.” > > There are two elements with just VC4. I think one of them > should have AC0 instead. > > Maybe VC3 and VC4 should have priority = 2? Otherwise they all have > priority=1, which isn’t useful. > > p 53 - remove VC3 from SS2 as I mentioned above. > > Section 18 MCC example. > > Looks like this one is an extension of previous, so any updates to > section 17 should apply here too. > > VC3 VC5 VC6 and VC7 should all have the same spatial information, same > as VC3 in section 17. > > Some captures should have lower priority, if they are all the same it > doesn’t help. > > I think VC7 should have this too: > > 3 > > VC7 also needs an encoding group > > EG0 > > Again, simultaneous sets don’t seem quite right. > > SS1: (SE1, VC3, VC7) I added VC3 > > SS2: (VC0, VC2, VC4) I removed VC7, because can’t do all the segments at > same time as VC4 zoomed out. > > Mark > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Sunday, December 13, 2015 10:41 AM > *To:* clue@ietf.org > *Cc:* Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; > danielcburnett@gmail.com; Duckworth, Mark > *Subject:* Short WGLC on > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 > > Hi guys, (I cc’ed those who reviewed the draft before) > > We had a WGLC on the 09 version a couple on month ago. The -11 version > supposedly address all issues. > > I would like to have a short 10 days WGLC till December 23^rd before > sending to publication. > > Please review > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 and see > if you are OK > > One open issue was if we need a IANA registry for the Policy attribute > (section 11.10) > > Thanks > > Roni > From nobody Fri Jan 8 09:58:45 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6DB1B2AAC; Fri, 8 Jan 2016 09:58:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160108175836.15341.63397.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 09:58:36 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-25.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, 08 Jan 2016 17:58:36 -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-25.txt Pages : 84 Date : 2016-01-08 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-framework-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-25 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 Jan 11 08:07:17 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 617381A1A7D; Fri, 8 Jan 2016 22:36:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160109063601.6773.10256.idtracker@ietfa.amsl.com> Date: Fri, 08 Jan 2016 22:36:01 -0800 Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 08:07:14 -0800 Cc: clue@ietf.org, clue-chairs@ietf.org Subject: [clue] clue - New Meeting Session Request for IETF 95 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, 09 Jan 2016 06:36:01 -0000 A new meeting session request has just been submitted by Roni Even, a Chair of the clue working group. --------------------------------------------------------- Working Group Name: ControLling mUltiple streams for tElepresence Area Name: Applications and Real-Time Area Session Requester: Roni Even Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: rmcat avtcore avtext mmusic payload rtcweb xrblock dispatch netvc perc Special Requests: --------------------------------------------------------- From nobody Thu Jan 14 09:10:31 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 757EA1A21C2; Thu, 14 Jan 2016 09:10:28 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160114171028.25074.62715.idtracker@ietfa.amsl.com> Date: Thu, 14 Jan 2016 09:10:28 -0800 Archived-At: Cc: alcoop@cisco.com, clue@ietf.org, The IESG , clue-chairs@ietf.org, draft-ietf-clue-framework@ietf.org, rfc-editor@rfc-editor.org Subject: [clue] Protocol Action: 'Framework for Telepresence Multi-Streams' to Proposed Standard (draft-ietf-clue-framework-25.txt) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 17:10:28 -0000 The IESG has approved the following document: - 'Framework for Telepresence Multi-Streams' (draft-ietf-clue-framework-25.txt) as Proposed Standard This document is the product of the ControLling mUltiple streams for tElepresence Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ Technical Summary: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document was discussed in the meeting, in conferences calls and on the mailing list. The open issues were addressed and there are no open issues, there was consensus on the content of the document. Document Quality: The actual protocol using the attributes defined in the network is almost done, it is aligned with this document and there is an implementation of the protocol. There are no specific reviews that need to be mentioned. Personnel: Roni Even is the Document Shepherd. The responsible AD is Alissa Cooper. From nobody Sun Jan 17 14:46:27 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0001A9073; Sun, 17 Jan 2016 14:46:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160117224626.25404.26449.idtracker@ietfa.amsl.com> Date: Sun, 17 Jan 2016 14:46:26 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-06.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 22:46:26 -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-06.txt Pages : 18 Date : 2016-01-17 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: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 08:29:20 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8501A1B3299; Thu, 21 Jan 2016 08:29:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> Date: Thu, 21 Jan 2016 08:29:18 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:29:18 -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-07.txt Pages : 36 Date : 2016-01-21 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: https://tools.ietf.org/html/draft-ietf-clue-signaling-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 21 08:53:37 2016 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 826321B32EF for ; Thu, 21 Jan 2016 08:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.902 X-Spam-Level: X-Spam-Status: No, score=-13.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVY7t2inmD_2 for ; Thu, 21 Jan 2016 08:53:33 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6D01B32EE for ; Thu, 21 Jan 2016 08:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3430; q=dns/txt; s=iport; t=1453395212; x=1454604812; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pNWUcTS+MTo4b/+O+HEO4WK4H0LyuEWuW7RgmlcpbI0=; b=FWVz+ILS/B83FVNTVKi+CFqH9hCNAb6ZcBT9Ahbp8V+tJXUdVglJwWtP ny6kp8P/inVdMbUsWqcur1z+2C+2RihXNfMHW/KffnUtqMCry1C9xgXGU R7emcpy5T2IwUtZiPUyMc8d9VufSsbLIKeqNVWUHJfrh1BKvdSAnVtzq2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5BQAKDKFW/xbLJq1ehAxtiFeeagUBg?= =?us-ascii?q?Q2UERgKhW0CggkBAQEBAQGBC4Q1AQEEAQEBNTYKEQsYCRYPCQMCAQIBFTATBgI?= =?us-ascii?q?BAYgXDr1jAQEBAQEFAQEBAQEBGoVwhTyJCAEElnWFRogRgV5Kg3qDBIVTjjxig?= =?us-ascii?q?2Y8LocjAQEB?= X-IronPort-AV: E=Sophos;i="5.22,326,1449532800"; d="scan'208";a="623666409" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2016 16:53:30 +0000 Received: from [10.47.200.59] ([10.47.200.59]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0LGrSJt017676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 21 Jan 2016 16:53:30 GMT Message-ID: <56A10D0B.2020509@cisco.com> Date: Thu, 21 Jan 2016 16:53:31 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> In-Reply-To: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 16:53:34 -0000 Hi all, apologies that this took longer than intended to revise and check. Thanks to all the reviewers - almost all suggestions were incorporated, usually as-is when suggested text was provided. * Removed the entire 'Media line directionality' section as a discussion of the pros/cons of using bidirectional vs unidirectional schemes wasn't suitable for a finalised version. The unidirectionality requirement is covered normatively in an earlier section. * BUNDLE no longer includes an address synchronisation step so the suggestion to wait until that done has been replaced with some general language about following any negotiated extensions. * Added OPTIONS negotiation to the example flow, and revised the flow to ensure it matched protocol document. * Section on not sending CLUE control media until CLUE negotiation completes narrowed to notify that only RTP should not be sent until negotiation completes and add RTCP to the list of things that should be sent as normal, in line with a=inactive. * Make explicit that m=recvonly lines don't need to have a label, as only m=sendonly lines are referenced by CLUE protocol messages. * Fix formatting of IANA sections. Improve syntax of feature tag section in line with Paul's suggestions. Definition of feature tag narrowed to be multiple media lines 'negotiated via CLUE protocol' rather than more generic 'multiple media lines'. One thing that Paul brought up was that in 5.1 "Later there are references to named states and transitions in the clue protocol. These don't seem to be consistent with the current state machine definitions" - I've checked and to me they seem to be consistent with the state machines in the protocol document. Rob On 21/01/16 16:29, 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 : CLUE Signaling > Authors : Paul Kyzivat > Lennard Xiao > Christian Groves > Robert Hansen > Filename : draft-ietf-clue-signaling-07.txt > Pages : 36 > Date : 2016-01-21 > > 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: > https://tools.ietf.org/html/draft-ietf-clue-signaling-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jan 21 21:07:47 2016 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 8C7FE1B3846 for ; Thu, 21 Jan 2016 21:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_18=0.6, T_DKIM_INVALID=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 PJxJ6VeBs_Pc for ; Thu, 21 Jan 2016 21:07:44 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (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 CEF251B3847 for ; Thu, 21 Jan 2016 21:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=VV0Vso1moP/nlnqm6awZKTs18njwVE3enfQeO2mKW9E=; b=tP55Qi3rQ1mqEBWgOSFeafyMNg foWz/RuL4Gll730ov3xrR37VNLdozIqMCnBM8e0AAjD0QyPElhCCqqoNpkRvoaR/1oSsyAncLnW4b CgaeOKbOxnxlgVCWgJaS1X5PJ1/SLk4N9YeA1FYsa8pJL3pv49IXRg48oKPWwjiMhVzq7lZVRsQMz ga6sNd2JSnU3X7s2tQLkPVcZmPfy6TtE9BgSmo0PX3lmn5CsWRCrYQdS3/9oS0lK6F1PKZLKsx2i/ /gGbCOt79O7aaHVVPcl9ZoLSYp92EzX3sBlbmZth//3GnSU7/tfazCPbmY8QaHLB3U/McAJ+Xwiaq h8oqM+Cg==; Received: from ppp118-209-174-250.lns20.mel8.internode.on.net ([118.209.174.250]:52101 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1aMTwh-003ILk-Nz for clue@ietf.org; Fri, 22 Jan 2016 16:07:39 +1100 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> From: Christian Groves Message-ID: <56A1B915.6040800@nteczone.com> Date: Fri, 22 Jan 2016 16:07:33 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A10D0B.2020509@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.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: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2016 05:07:46 -0000 Hello Rob, Thanks for the update. A couple of comments: cl. 4.5.2.2 adds "lines for compatible encodings" - is compatible the right term here? Isn't it more "accepted encodings"? cl. 4.5.4.3: I've made a comment a couple of times now about the need to mention SCTP reset for disabling CLUE mid call but it appears to be missed. Both draft-ietf-clue-datachannel (cl.3.2.7) and draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) both mention that an SCTP SSN reset has to be performed. draft-ietf-mmusic-data-channel-sdpneg (cl.5.2.4) mentions that its protocol specific whether this is announced by SDP. So I would propose to word the first paragraph of cl.4.5.4.3 differently: "If order to close a CLUE data channel in an ongoing CLUE-enabled call, an endpoint shall follow the procedures for closing a data channel defined in clause 5.2.4 [draft-ietf-mmusic-data-channel-sdpneg] by sending a new SDP offer/answer exchange and subsequent SCTP SSN reset for the CLUE channel. In the event that this occurs, CLUE is no longer enabled and sending of all CLUE-controlled media associated with the corresponding CLUE group MUST stop. If the data channel is still present but not included in the CLUE group semantic CLUE protocol messages MUST no longer be sent." Regards, Christian On 22/01/2016 3:53 AM, Robert Hansen wrote: > Hi all, apologies that this took longer than intended to revise and > check. > > Thanks to all the reviewers - almost all suggestions were > incorporated, usually as-is when suggested text was provided. > > * Removed the entire 'Media line directionality' section as a > discussion of the pros/cons of using bidirectional vs unidirectional > schemes wasn't suitable for a finalised version. The unidirectionality > requirement is covered normatively in an earlier section. > > * BUNDLE no longer includes an address synchronisation step so the > suggestion to wait until that done has been replaced with some general > language about following any negotiated extensions. > > * Added OPTIONS negotiation to the example flow, and revised the flow > to ensure it matched protocol document. > > * Section on not sending CLUE control media until CLUE negotiation > completes narrowed to notify that only RTP should not be sent until > negotiation completes and add RTCP to the list of things that should > be sent as normal, in line with a=inactive. > > * Make explicit that m=recvonly lines don't need to have a label, as > only m=sendonly lines are referenced by CLUE protocol messages. > > * Fix formatting of IANA sections. Improve syntax of feature tag > section in line with Paul's suggestions. Definition of feature tag > narrowed to be multiple media lines 'negotiated via CLUE protocol' > rather than more generic 'multiple media lines'. > > One thing that Paul brought up was that in 5.1 "Later there are > references to named states and transitions in the clue protocol. These > don't seem to be consistent with the current state machine > definitions" - I've checked and to me they seem to be consistent with > the state machines in the protocol document. > > Rob > > On 21/01/16 16:29, 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 : CLUE Signaling >> Authors : Paul Kyzivat >> Lennard Xiao >> Christian Groves >> Robert Hansen >> Filename : draft-ietf-clue-signaling-07.txt >> Pages : 36 >> Date : 2016-01-21 >> >> 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: >> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jan 25 12:42:50 2016 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 6AEC81A0199 for ; Mon, 25 Jan 2016 12:42:48 -0800 (PST) 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_18=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 b8gzRZWRfZ2M for ; Mon, 25 Jan 2016 12:42:46 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76B21A01A5 for ; Mon, 25 Jan 2016 12:42:46 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-07v.sys.comcast.net with comcast id ALik1s0032S2Q5R01Limln; Mon, 25 Jan 2016 20:42:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id ALil1s00C3KdFy101LilfL; Mon, 25 Jan 2016 20:42:45 +0000 To: clue@ietf.org References: <20160121162918.2158.51064.idtracker@ietfa.amsl.com> <56A10D0B.2020509@cisco.com> From: Paul Kyzivat Message-ID: <56A688C4.3010906@alum.mit.edu> Date: Mon, 25 Jan 2016 15:42:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56A10D0B.2020509@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1453754566; bh=klihtrrBkl0E84ggteETsXSUI87ikOXLeecFyMHYyAw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=FqXNpShqUrMaPNmMW4H0ib3/oCGfw6V0x6BX1x8srE9Ox/VBPJwRy1+CwRWHElmO5 v7d5LXYh5tV1TFm6pONPJItOAIYhbBDG7FFgMAqsCvdBbdunpsdEBUirMwGvD0tw19 EGJI0QZje7FYgjaT40J//XLbJBsMTqNS9jU39p1S0hc0a/DytyNPxWewWY+lF945Ls bSOzbdr7M7TDzTl7c0JMvl8i/VLyvGsO0pcgXmuuV367+QRRVXyB/8c67rM0tNhLMR ppbvVK9mS088OM/dFYDu4jDQ4ZujVQs8nRphzupts3ThTh7oDwe8hm/M/qMyY7ZuMt 13Rtqzoy+ZEwg== Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 20:42:48 -0000 On 1/21/16 11:53 AM, Robert Hansen wrote: > Hi all, apologies that this took longer than intended to revise and check. > > Thanks to all the reviewers - almost all suggestions were incorporated, > usually as-is when suggested text was provided. This generally looks good. I found a few nits while reading: * Section 4.5.3.1: s/"m=" line to send or receive/"m=" lines to send or receive/ * Section 4.5.4.3: s/distinct to/distinct from/ (This isn't new, I missed it previously.) As written I think it means the opposite of what it intends. * Section 8: Did you attempt to address my comments in: http://mailarchive.ietf.org/arch/msg/clue/gYAy7v42JN8uxFz53qxBVki7OBY I see a few of the editorial ones addressed, but not the substantial ones. For the most part the meaty ones still apply. Thanks, Paul > * Removed the entire 'Media line directionality' section as a discussion > of the pros/cons of using bidirectional vs unidirectional schemes wasn't > suitable for a finalised version. The unidirectionality requirement is > covered normatively in an earlier section. > > * BUNDLE no longer includes an address synchronisation step so the > suggestion to wait until that done has been replaced with some general > language about following any negotiated extensions. > > * Added OPTIONS negotiation to the example flow, and revised the flow to > ensure it matched protocol document. > > * Section on not sending CLUE control media until CLUE negotiation > completes narrowed to notify that only RTP should not be sent until > negotiation completes and add RTCP to the list of things that should be > sent as normal, in line with a=inactive. > > * Make explicit that m=recvonly lines don't need to have a label, as > only m=sendonly lines are referenced by CLUE protocol messages. > > * Fix formatting of IANA sections. Improve syntax of feature tag > section in line with Paul's suggestions. Definition of feature tag > narrowed to be multiple media lines 'negotiated via CLUE protocol' > rather than more generic 'multiple media lines'. > > One thing that Paul brought up was that in 5.1 "Later there are > references to named states and transitions in the clue protocol. These > don't seem to be consistent with the current state machine definitions" > - I've checked and to me they seem to be consistent with the state > machines in the protocol document. > > Rob > > On 21/01/16 16:29, 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 : CLUE Signaling >> Authors : Paul Kyzivat >> Lennard Xiao >> Christian Groves >> Robert Hansen >> Filename : draft-ietf-clue-signaling-07.txt >> Pages : 36 >> Date : 2016-01-21 >> >> 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: >> https://tools.ietf.org/html/draft-ietf-clue-signaling-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-07 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jan 25 13:02:50 2016 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 0BBEA1A020A for ; Mon, 25 Jan 2016 13:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpEgmQQItkte for ; Mon, 25 Jan 2016 13:02:46 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70D1A0217 for ; Mon, 25 Jan 2016 13:02:46 -0800 (PST) X-AuditID: 12074414-f794f6d000007852-08-56a68d750a05 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 65.01.30802.57D86A65; Mon, 25 Jan 2016 16:02:45 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u0PL2jIm001103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 25 Jan 2016 16:02:45 -0500 To: CLUE From: Paul Kyzivat Message-ID: <56A68D72.1060900@alum.mit.edu> Date: Mon, 25 Jan 2016 16:02:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixO6iqFvauyzMYOsKC4v9py4zOzB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+PKxq2sBY1sFUdW3mNsYHzD0sXIySEhYCLx+exnKFtM4sK9 9WwgtpDAZUaJk7fLuxi5gOyfTBI7fh9jB0mICEhInDp1lxHEZhPQkphz6D9QMweHsICuxPNz ciBhXgFtiX/rHzOD2CwCqhLXDhwDs0UF0iT2z/7NBFEjKHFy5hOwvcwCZhLzNj9khrDlJba/ ncM8gZF3FpKyWUjKZiEpW8DIvIpRLjGnNFc3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMj JJhEdjAeOSl3iFGAg1GJh3dDwbIwIdbEsuLK3EOMkhxMSqK87JVAIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8wV1AOd6UxMqq1KJ8mJQ0B4uSOO+3xep+QgLpiSWp2ampBalFMFkZDg4lCd7n 3UCNgkWp6akVaZk5JQhpJg5OkOFcUiLFqXkpqUWJpSUZ8aD4ii8GRhhIigdo7xOQdt7igsRc oChE6ylGXY4FP26vZRJiycvPS5US5z0GUiQAUpRRmge3ApY6XjGKA30szMvSA1TFA0w7cJNe AS1hAlryV3MxyJKSRISUVAOjdu3Nvd4Wswwd4xpmszU1py32iv/jfSnU+v0qF9YirwcmxnLc EYbrhDz0cv/dEeyQaPN5tfdhukHgc44vx3dn+G1U3vPkiXHA/keWRfJ9ksdanX8cCr4Wemk7 y/LJXXsNWivkz8//rl9kf+LHQf6Zgi09D9fsq1ng8PSc/suaG/UlwspFJ/uVWIozEg21mIuK EwEdcnRt+AIAAA== Archived-At: Subject: [clue] Security Considerations for protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2016 21:02:49 -0000 I was just reviewing the security considerations sections of the various documents, in prep for proposing something for the protocol document. Right now the data model document has some security considerations while the protocol does not. I have mixed feelings of how info should be split among these documents. Clearly they aren't independent, since most of the "interesting/important" information from a security perspective is defined in the data model. Of course the data model is just a model, it doesn't define to whom this information is sent, or how. So it can't do a very complete job of addressing security concerns. I am inclined to suggest that the data model defer to the protocol for the security considerations. Thanks, Paul From nobody Wed Jan 27 05:59:41 2016 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 7C0AF1B2E56 for ; Wed, 27 Jan 2016 05:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-B98gu9ZOpi for ; Wed, 27 Jan 2016 05:59:34 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (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 A9CA51B2E0F for ; Wed, 27 Jan 2016 05:59:34 -0800 (PST) Received: from [216.82.242.36] by server-11.bemta-8.messagelabs.com id 9A/F0-05489-54DC8A65; Wed, 27 Jan 2016 13:59:33 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-12.tower-94.messagelabs.com!1453903172!23618016!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 37655 invoked from network); 27 Jan 2016 13:59:33 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-12.tower-94.messagelabs.com with AES128-SHA encrypted SMTP; 27 Jan 2016 13:59:33 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.113]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 27 Jan 2016 05:59:32 -0800 From: "Duckworth, Mark" To: "roberta.presta@unina.it" , "Simon Pietro Romano (spromano@unina.it)" Date: Wed, 27 Jan 2016 05:59:30 -0800 Thread-Topic: Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 Thread-Index: AdE4Rtahd2HY8M3hTMS/Dtzk7MzYMAgw7g9A Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@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_5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2016 13:59:39 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Roberta and Simon, I could volunteer to do the editing work on the example section, if you agr= ee with my proposed changes below. Would you like me to do that? Mark From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Wednesday, December 16, 2015 4:15 PM To: Roni Even; clue@ietf.org Subject: [clue] Mark's comments RE: Short WGLC on https://tools.ietf.org/ht= ml/draft-ietf-clue-data-model-schema-11 Hi, Section 4, why did maxCaptureType change from unsignedInt to positiveIntege= r? I thought we agreed not to use the unbounded integer types. Is it just t= o disallow the value zero? Is there another way to do that without allowing= unbounded values? I had a few comments way back on draft 07, some of which didn't seem to be add= ressed. I think they are still worthwhile considering, so I include them ag= ain here. Section 17 example "... endpoint-style Media Provider's offer". I think it should be "... end= point-style Media Provider's advertisement" Section 17 p 48 simultaneous sets - I think it makes more sense to say you = can't provide the loudest segment at same time as the zoomed out view, beca= use they would be using the same camera at different zoom levels in this ex= ample. So VC3 and VC4 can't be simultaneous. So then SS2 should be just (V= C0, VC2, VC4). The spatial information in the sample file doesn't make sense, it looks lik= e just a placeholder because it is identical for all captures. I have this = proposal for spatial information. AC0 0.0 0.0 10.0 0.0 1.0 10.0 VC0 - left -2.0 0.0 10.0 -3.0 20.0 9.0 -1.0 20.0 9.0 -3.0 20.0 11.0 -1.0 20.0 11.0 VC1 - center 0.0 0.0 10.0 -1.0 20.0 9.0 1.0 20.0 9.0 -1.0 20.0 11.0 1.0 20.0 11.0 VC2 - right 2.0 0.0 10.0 1.0 20.0 9.0 3.0 20.0 9.0 1.0 20.0 11.0 3.0 20.0 11.0 VC3 - loudest segment -3.0 20.0 9.0 3.0 20.0 9.0 -3.0 20.0 11.0 3.0 20.0 11.0 VC4 - zoomed out 0.0 0.0 10.0 -3.0 20.0 7.0 3.0 20.0 7.0 -3.0 20.0 13.0 3.0 20.0 13.0 I suggest VC3 should have spatial information, rather than true, because the framework says "For a switched Capture that switch= es between different sections within a larger area, the area of capture MUS= T use coordinates for the larger potential area." There are two elements with just VC4. I think one of them shou= ld have AC0 instead. Maybe VC3 and VC4 should have priority =3D 2? Otherwise they all have prio= rity=3D1, which isn't useful. p 53 - remove VC3 from SS2 as I mentioned above. Section 18 MCC example. Looks like this one is an extension of previous, so any updates to section = 17 should apply here too. VC3 VC5 VC6 and VC7 should all have the same spatial information, same as V= C3 in section 17. Some captures should have lower priority, if they are all the same it doesn= 't help. I think VC7 should have this too: 3 VC7 also needs an encoding group EG0 Again, simultaneous sets don't seem quite right. SS1: (SE1, VC3, VC7) I added VC3 SS2: (VC0, VC2, VC4) I removed VC7, because can't do all the segments at sa= me time as VC4 zoomed out. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Sunday, December 13, 2015 10:41 AM To: clue@ietf.org Cc: Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; danielcburnett@g= mail.com; Duckworth, Mark Subject: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-mod= el-schema-11 Hi guys, (I cc'ed those who reviewed the draft before) We had a WGLC on the 09 version a couple on month ago. The -11 version supp= osedly address all issues. I would like to have a short 10 days WGLC till December 23rd before sending= to publication. Please review https://tools.ietf.org/html/draft-ietf-clue-data-model-schema= -11 and see if you are OK One open issue was if we need a IANA registry for the Policy attribute (sec= tion 11.10) Thanks Roni --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Roberta and Simon,

I could volunteer to do the editing wor= k on the example section, if you agree with my proposed changes below. Woul= d you like me to do that?

 

Mark

<= span style=3D'color:#1F497D'> 

From: clue [mailto:clue-bounces@ietf.org] On Behal= f Of Duckworth, Mark
Sent: Wednesday, December 16, 2015 4:15 = PM
To: Roni Even; clue@ietf.org
Subject: [clue] Mark's = comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data= -model-schema-11

 

Hi,

&= nbsp;

Se= ction 4, why did maxCaptureType change from unsignedInt to positiveInteger?= I thought we agreed not to use the unbounded integer types. Is it just to = disallow the value zero? Is there another way to do that without allowing u= nbounded values?

 

I had a few comments way back on draft 07, s= ome of which didn’t seem to be addressed. I think they are still wort= hwhile considering, so I include them again here.

 

=

Section 17 example

= “... endpoint-style Media Provider’s offer”.  I thin= k it should be “... endpoint-style Media Provider’s advertiseme= nt”

=  

Section 17 p 48 simultaneous sets – I think it makes more = sense to say you can’t provide the loudest segment at same time as th= e zoomed out view, because they would be using the same camera at different= zoom levels in this example.  So VC3 and VC4 can’t be simultane= ous. So then SS2 should be just (VC0, VC2, VC4).

 

The spatial information i= n the sample file doesn’t make sense, it looks like just a placeholde= r because it is identical for all captures. I have this proposal for spatia= l information.

AC0

<capturePoint>

  <x&g= t;0.0</x>

  <y>0.0</y>

  <= z>10.0</z>

  <lineOfCapturePoint>=

&= nbsp;   <x>0.0</x>

    <y&= gt;1.0</y>

    <z>10.0</z>

</capturePoint>

VC0 - left

<capturePoint>

 = <x>-2.0</x>

  <y>0.0</y><= /span>

&n= bsp; <z>10.0</z>

</capturePoint>

<ca= ptureArea>

  <bottomLeft>  <x>-3.0</x&= gt; <y>20.0</y> <z>9.0</z> </bottomLeft>=

  <bottomRight> <x>-1.0</x> <y>20.0</y= > <z>9.0</z> </bottomRight>

  <topLef= t>     <x>-3.0</x> <y>20.0</y&g= t; <z>11.0</z> </topLeft>

  <topRight&= gt;    <x>-1.0</x> <y>20.0</y> <z= >11.0</z> </topRight>

</captureArea>

 

VC1 - center

<capturePoint>

 = <x>0.0</x>

  <y>0.0</y>

&nb= sp; <z>10.0</z>

</capturePoint>

<cap= tureArea>

  <bottomLeft>  <x>-1.0</x&g= t; <y>20.0</y> <z>9.0</z> </bottomLeft><= /o:p>

  <bottomRight> <x>1.0</x>  <y>20.0&l= t;/y> <z>9.0</z> </bottomRight>

<= p class=3DMsoNormal>  <to= pLeft>     <x>-1.0</x> <y>20.0<= /y> <z>11.0</z> </topLeft>

  <topRigh= t>    <x>1.0</x>  <y>20.0</y>= ; <z>11.0</z> </topRight>

</captureArea>=

 

VC2 - right

<capturePoint>

  <y>0.0</y>=

  <z>10.0</z>

</capturePoint>

<captureArea>

  <bottomLeft>  <x>1.0= </x> <y>20.0</y> <z>9.0</z> </bottomLeft&g= t;

  <bottomRight> <x>3.0</x> <y>20.0= </y> <z>9.0</z> </bottomRight>

  <= topLeft>     <x>1.0</x> <y>20.0<= ;/y> <z>11.0</z> </topLeft>

  <topRig= ht>    <x>3.0</x> <y>20.0</y> <= ;z>11.0</z> </topRight>

</captureArea>

VC3 - loudest segment

<captureArea><= /o:p>

  <bottomLeft>  <x>-3.0</x> <y>20.0&l= t;/y> <z>9.0</z> </bottomLeft>

  <bot= tomRight> <x>3.0</x>  <y>20.0</y> <z>= 9.0</z> </bottomRight>

  <topLeft> &nb= sp;   <x>-3.0</x> <y>20.0</y> <z>11= .0</z> </topLeft>

  <topRight>  &= nbsp; <x>3.0</x>  <y>20.0</y> <z>11.0<= ;/z> </topRight>

</captureArea>

 = ;

VC4 - zoomed out

<capturePoint>

<= p class=3DMsoNormal>  <x&= gt;0.0</x>

  <y>0.0</y>

  <= ;z>10.0</z>

</capturePoint>

<= p class=3DMsoNormal><captureAr= ea>

  <bottomLeft>  <x>-3.0</x> <= ;y>20.0</y> <z>7.0</z> </bottomLeft><= /span>

&n= bsp; <bottomRight> <x>3.0</x>  <y>20.0</y&g= t; <z>7.0</z> </bottomRight>

  <topLeft&= gt;     <x>-3.0</x> <y>20.0</y>= <z>13.0</z> </topLeft>

  <topRight>&= nbsp;   <x>3.0</x>  <y>20.0</y> <= z>13.0</z> </topRight>

</captureArea>

 

I suggest VC3 should have spatial information, rather than <nonSpatial= lyDefinable>true, because the framework says “For a switched Captu= re that switches between different sections within a larger area, the area = of capture MUST use coordinates for the larger potential area.”<= /o:p>

 

The= re are two <sceneView> elements with just VC4.  I think one of t= hem should have AC0 instead.

 =

Maybe VC3 and VC4 should have priority =3D 2= ?  Otherwise they all have priority=3D1, which isn’t useful.

 

p= 53 - remove VC3 from SS2 as I mentioned above.

 

Section 18 MCC example.

 

Looks like this one is an extension of previous, so any updates to section= 17 should apply here too.

VC3 VC5 VC6 a= nd VC7 should all have the same spatial information, same as VC3 in section= 17.

Some captures should have lower pri= ority, if they are all the same it doesn’t help.

I think VC7 should have this too:

<maxCaptures exactNumber=3D”true”>3</maxCaptu= res>

VC7 also needs an encoding group=

<encGroupIDREF>EG0</encGroupID= REF>

Again, simultaneous sets donR= 17;t seem quite right.

SS1: (SE1, VC3, V= C7) I added VC3

SS2: (VC0, VC2, VC4) I r= emoved VC7, because can’t do all the segments at same time as VC4 zoo= med out.

<= o:p> 

Mark

 

= From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Sunday, Dece= mber 13, 2015 10:41 AM
To: clue@ietf.org
Cc: Rob Hansen= (rohanse2); Christian Groves; Paul Kyzivat; danielcburnett@gmail.com; Duck= worth, Mark
Subject: Short WGLC on https://tools.ietf.org/html/dr= aft-ietf-clue-data-model-schema-11

 

Hi guys, (I cc̵= 7;ed those who reviewed the draft before)

 

We had a WGLC on the 09 version= a couple on month ago. The -11 version supposedly address all issues.=

I would like to have a short 10 days WGLC ti= ll December 23rd before sending to publication.

<= p class=3DMsoNormal>Please review https://tools.ietf.org/html/draft-ietf-= clue-data-model-schema-11 and see if you are OK

 

One open issue was i= f we need a IANA registry for the Policy attribute (section 11.10)

 

Thanks=

Roni

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7CRPMBOXPRD08p_-- From nobody Thu Jan 28 04:05:36 2016 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 8E4151B3C7D for ; Thu, 28 Jan 2016 04:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.379 X-Spam-Level: * X-Spam-Status: No, score=1.379 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZC4TQmtFOe8 for ; Thu, 28 Jan 2016 04:05:31 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA811B3C86 for ; Thu, 28 Jan 2016 04:05:30 -0800 (PST) X-ASG-Debug-ID: 1453982724-05f275259571010001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id imkU1UaQ09qBft9J (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2016 13:05:25 +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] ([100.102.148.48]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id u0SC5Nl2002326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jan 2016 13:05:24 +0100 From: Roberta Presta To: "Duckworth, Mark" , "clue@ietf.org" X-ASG-Orig-Subj: Re: Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 References: <5C4AC54BFF7A0842A6A11F554D6FB52FC172A058EF@CRPMBOXPRD08.polycom.com> <5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7@CRPMBOXPRD08.polycom.com> Message-ID: <56AA0404.2020804@unina.it> Date: Thu, 28 Jan 2016 13:05:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52FC172CA46E7@CRPMBOXPRD08.polycom.com> Content-Type: multipart/alternative; boundary="------------030403040304050905040009" X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1453982725 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-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.26531 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: Re: [clue] Mark's comments RE: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 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, 28 Jan 2016 12:05:35 -0000 This is a multi-part message in MIME format. --------------030403040304050905040009 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Mark, thank you very much for the review. We are uploading the corrected version of the draft. Please find below our answers to your comments. Il 27/01/2016 14:59, Duckworth, Mark ha scritto: > > Section 4, why did maxCaptureType change from unsignedInt to > positiveInteger? I thought we agreed not to use the unbounded integer > types. Is it just to disallow the value zero? Is there another way to > do that without allowing unbounded values? > We initially applied a suggestion from Rob Hansen. Now we changed the definition as in the following: > > Section 17 example > > “... endpoint-style Media Provider’s offer”. I think it should be > “... endpoint-style Media Provider’s advertisement” > Done. > > Section 17 p 48 simultaneous sets – I think it makes more sense to say > you can’t provide the loudest segment at same time as the zoomed out > view, because they would be using the same camera at different zoom > levels in this example. So VC3 and VC4 can’t be simultaneous. So then > SS2 should be just (VC0, VC2, VC4). > Correct. Done. > The spatial information in the sample file doesn’t make sense, it > looks like just a placeholder because it is identical for all > captures. I have this proposal for spatial information. > > AC0 > > > > 0.0 > > 0.0 > > 10.0 > > > > 0.0 > > 1.0 > > 10.0 > > > > > > VC0 - left > > > > -2.0 > > 0.0 > > 10.0 > > > > > > -3.0 20.0 9.0 > > -1.0 20.0 9.0 > > -3.0 20.0 11.0 > > -1.0 20.0 11.0 > > > > VC1 - center > > > > 0.0 > > 0.0 > > 10.0 > > > > > > -1.0 20.0 9.0 > > 1.0 20.0 9.0 > > -1.0 20.0 11.0 > > 1.0 20.0 11.0 > > > > VC2 - right > > > > 2.0 > > 0.0 > > 10.0 > > > > > > 1.0 20.0 9.0 > > 3.0 20.0 9.0 > > 1.0 20.0 11.0 > > 3.0 20.0 11.0 > > > > VC3 - loudest segment > > > > -3.0 20.0 9.0 > > 3.0 20.0 9.0 > > -3.0 20.0 11.0 > > 3.0 20.0 11.0 > > > > VC4 - zoomed out > > > > 0.0 > > 0.0 > > 10.0 > > > > > > -3.0 20.0 7.0 > > 3.0 20.0 7.0 > > -3.0 20.0 13.0 > > 3.0 20.0 13.0 > > > > I suggest VC3 should have spatial information, rather than > true, because the framework says “For a > switched Capture that switches between different sections within a > larger area, the area of capture MUST use coordinates for the larger > potential area.” > OK. Done. > > There are two elements with just VC4. I think one of them > should have AC0 instead. > Right. Done. > > Maybe VC3 and VC4 should have priority = 2? Otherwise they all have > priority=1, which isn’t useful. > Done. > > p 53 - remove VC3 from SS2 as I mentioned above. > Done. > > Section 18 MCC example. > > Looks like this one is an extension of previous, so any updates to > section 17 should apply here too. > Done. > > VC3 VC5 VC6 and VC7 should all have the same spatial information, same > as VC3 in section 17. > Ok. > > Some captures should have lower priority, if they are all the same > it doesn’t help. > OK. We removed priority from VC5 and VC6, that are not to be sent, and set VC7 priority equal to 3. > I think VC7 should have this too: > > 3 > It is not strictly necessary since we stated that " If is not provided, all the media captures listed in the element can appear at a time in the capture encoding. " However, we have modified the example as you suggested. > VC7 also needs an encoding group > > EG0 > Right. Done. > > Again, simultaneous sets don’t seem quite right. > > SS1: (SE1, VC3, VC7) I added VC3 > > SS2: (VC0, VC2, VC4) I removed VC7, because can’t do all the segments > at same time as VC4 zoomed out. > Right. Done. Thank you again! Roberta > Mark > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Sunday, December 13, 2015 10:41 AM > *To:* clue@ietf.org > *Cc:* Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; > danielcburnett@gmail.com; Duckworth, Mark > *Subject:* Short WGLC on > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 > > Hi guys, (I cc’ed those who reviewed the draft before) > > We had a WGLC on the 09 version a couple on month ago. The -11 version > supposedly address all issues. > > I would like to have a short 10 days WGLC till December 23^rd before > sending to publication. > > Please review > https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 and > see if you are OK > > One open issue was if we need a IANA registry for the Policy attribute > (section 11.10) > > Thanks > > Roni > --------------030403040304050905040009 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear Mark,
thank you very much for the review. We are uploading the corrected version of the draft.
Please find below our answers to your comments.

Il 27/01/2016 14:59, Duckworth, Mark ha scritto:

 

Section 4, why did maxCaptureType change from unsignedInt to positiveInteger? I thought we agreed not to use the unbounded integer types. Is it just to disallow the value zero? Is there another way to do that without allowing unbounded values?


We initially applied a suggestion from Rob Hansen.
Now we changed the definition as in the following:
<!-- MAX CAPTURES TYPE -->
<xs:complexType name="maxCapturesType">
  <xs:simpleContent>
    <xs:extension base="xs:unsignedShort">
      <xs:minInclusive value="1"/>   
      <xs:attribute name="exactNumber" type="xs:boolean"/>
    </xs:extension>
  </xs:simpleContent>
</xs:complexType>


 


 

Section 17 example

“... endpoint-style Media Provider’s offer”.  I think it should be “... endpoint-style Media Provider’s advertisement”

Done.

 

Section 17 p 48 simultaneous sets – I think it makes more sense to say you can’t provide the loudest segment at same time as the zoomed out view, because they would be using the same camera at different zoom levels in this example.  So VC3 and VC4 can’t be simultaneous. So then SS2 should be just (VC0, VC2, VC4).

 

Correct. Done.

The spatial information in the sample file doesnÂ’t make sense, it looks like just a placeholder because it is identical for all captures. I have this proposal for spatial information.

AC0

<capture    Point>

  <x>0.0</x>

  <y>0.0</y>

  <z>10.0</z>

  <lineOfCapturePoint>

    <x>0.0</x>

    <y>1.0</y>

    <z>10.0</z>

  </lineOfCapturePoint>

</capturePoint>

 

VC0 - left

<capturePoint>

  <x>-2.0</x>

  <y>0.0</y>

  <z>10.0</z>

</capturePoint>

<captureArea>

  <bottomLeft>  <x>-3.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft>

  <bottomRight> <x>-1.0</x> <y>20.0</y> <z>9.0</z> </bottomRight>

  <topLeft>     <x>-3.0</x> <y>20.0</y> <z>11.0</z> </topLeft>

  <topRight>    <x>-1.0</x> <y>20.0</y> <z>11.0</z> </topRight>

</captureArea>

 

VC1 - center

<capturePoint>

  <x>0.0</x>

  <y>0.0</y>

  <z>10.0</z>

</capturePoint>

<captureArea>

  <bottomLeft>  <x>-1.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft>

  <bottomRight> <x>1.0</x>  <y>20.0</y> <z>9.0</z> </bottomRight>

  <topLeft>     <x>-1.0</x> <y>20.0</y> <z>11.0</z> </topLeft>

  <topRight>    <x>1.0</x>  <y>20.0</y> <z>11.0</z> </topRight>

</captureArea>

 

VC2 - right

<capturePoint>

  <x>2.0</x>

  <y>0.0</y>

  <z>10.0</z>

</capturePoint>

<captureArea>

  <bottomLeft>  <x>1.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft>

  <bottomRight> <x>3.0</x> <y>20.0</y> <z>9.0</z> </bottomRight>

  <topLeft>     <x>1.0</x> <y>20.0</y> <z>11.0</z> </topLeft>

  <topRight>    <x>3.0</x> <y>20.0</y> <z>11.0</z> </topRight>

</captureArea>

 

VC3 - loudest segment

<captureArea>

  <bottomLeft>  <x>-3.0</x> <y>20.0</y> <z>9.0</z> </bottomLeft>

  <bottomRight> <x>3.0</x>  <y>20.0</y> <z>9.0</z> </bottomRight>

  <topLeft>     <x>-3.0</x> <y>20.0</y> <z>11.0</z> </topLeft>

  <topRight>    <x>3.0</x>  <y>20.0</y> <z>11.0</z> </topRight>

</captureArea>

 

VC4 - zoomed out

<capturePoint>

  <x>0.0</x>

  <y>0.0</y>

  <z>10.0</z>

</capturePoint>

<captureArea>

  <bottomLeft>  <x>-3.0</x> <y>20.0</y> <z>7.0</z> </bottomLeft>

  <bottomRight> <x>3.0</x>  <y>20.0</y> <z>7.0</z> </bottomRight>

  <topLeft>     <x>-3.0</x> <y>20.0</y> <z>13.0</z> </topLeft>

  <topRight>    <x>3.0</x>  <y>20.0</y> <z>13.0</z> </topRight>

</captureArea>

 

I suggest VC3 should have spatial information, rather than <nonSpatiallyDefinable>true, because the framework says “For a switched Capture that switches between different sections within a larger area, the area of capture MUST use coordinates for the larger potential area.”

 

OK. Done.

There are two <sceneView> elements with just VC4.  I think one of them should have AC0 instead.

Right. Done.

 

Maybe VC3 and VC4 should have priority = 2?  Otherwise they all have priority=1, which isn’t useful.

Done.

 

p 53 - remove VC3 from SS2 as I mentioned above.

 

Done.

Section 18 MCC example.

 

Looks like this one is an extension of previous, so any updates to section 17 should apply here too.

Done.

VC3 VC5 VC6 and VC7 should all have the same spatial information, same as VC3 in section 17.

Ok.

Some captures should have lower priority, if they are all the same it doesnÂ’t help.

OK. We removed priority from VC5 and VC6, that are not to be sent, and set VC7 priority equal to 3.

I think VC7 should have this too:

<maxCaptures exactNumber=”true”>3</maxCaptures>

It is not strictly necessary since we stated that " 
If <maxCaptures> is not provided, all the
   media captures listed in the <content> element can appear at a time
   in the capture encoding.
"
However, we have modified the example as you suggested.

VC7 also needs an encoding group

<encGroupIDREF>EG0</encGroupIDREF>

Right. Done.

Again, simultaneous sets donÂ’t seem quite right.

SS1: (SE1, VC3, VC7) I added VC3

SS2: (VC0, VC2, VC4) I removed VC7, because canÂ’t do all the segments at same time as VC4 zoomed out.

 

Right. Done.
Thank  you again!

Roberta

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Sunday, December 13, 2015 10:41 AM
To: clue@ietf.org
Cc: Rob Hansen (rohanse2); Christian Groves; Paul Kyzivat; danielcburnett@gmail.com; Duckworth, Mark
Subject: Short WGLC on https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11

 

Hi guys, (I ccÂ’ed those who reviewed the draft before)

 

We had a WGLC on the 09 version a couple on month ago. The -11 version supposedly address all issues.

I would like to have a short 10 days WGLC till December 23rd before sending to publication.

Please review https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-11 and see if you are OK

 

One open issue was if we need a IANA registry for the Policy attribute (section 11.10)

 

Thanks

Roni


--------------030403040304050905040009-- From nobody Thu Jan 28 06:54:19 2016 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 989B31A8863; Thu, 28 Jan 2016 06:54:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160128145416.10147.51914.idtracker@ietfa.amsl.com> Date: Thu, 28 Jan 2016 06:54:16 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2016 14:54: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 : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-12.txt Pages : 72 Date : 2016-01-28 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-12 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/