From nobody Mon Feb 2 06:19:24 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D91A1AFB for ; Mon, 2 Feb 2015 06:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-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 G8ZNziKMK8MX for ; Mon, 2 Feb 2015 06:19:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 E1B741A1A93 for ; Mon, 2 Feb 2015 06:17:29 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 20114BFB96A for ; Mon, 2 Feb 2015 14:17:25 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t12EHRrO019697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 2 Feb 2015 15:17:27 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.123]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 15:17:27 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "clue@ietf.org" Thread-Topic: Def. "CLUE data channel" Thread-Index: AdA+8lTnX8LbHFR9ShKl8PwflfPSrQ== Date: Mon, 2 Feb 2015 14:17:27 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC4B3831E5@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [clue] Def. "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: Mon, 02 Feb 2015 14:19:23 -0000 Like to propose a clarification/enhancement of the WebRTC DC definition in = CLUE: draft-ietf-clue-datachannel-07=20 2. Conventions ... WebRTC Data Channel refers to a SCTPoDTLS association [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media data between two entities, according to the procedures in [I-D.ietf-rtcweb-data-channel]. CLUE data channel refers to a WebRTC Data Channel [I-D.ietf-rtcweb-data-channel] realization, with a specific set of SCTP characteristics, with the purpose of transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities. Issue: the paragraph, as a summary of clause 6.4/draft-ietf-rtcweb-data-channel-13= , seems to be a too high abstraction (because equating a "WebRTC DC" entity= with a "SCTPoDTLS" association entity), however, the level of SCTP stream = is missing. Like to suggest following enhancement: WebRTC Data Channel: represents an SCTP stream level object, constituted by= a pair of one incoming SCTP stream and one outgoing SCTP stream (with iden= tical SCTP stream identifier values), using the transport of a SCTPoDTLS as= sociation [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-m= edia data between two entities, according to the procedures in [I-D.ietf-rt= cweb-data-channel]. Regards, Albrecht PS The definition of CLUE data channel is not affect because refering to the "= realization" section in clause 6.4/draft-ietf-rtcweb-data-channel. From nobody Wed Feb 4 02:50:40 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60B1A86EC for ; Wed, 4 Feb 2015 02:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8wglBO6Ckjx for ; Wed, 4 Feb 2015 02:50:37 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED96E1A1A92 for ; Wed, 4 Feb 2015 02:50:36 -0800 (PST) Received: from ppp118-209-101-219.lns20.mel4.internode.on.net ([118.209.101.219]:53067 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YIxVw-0007fy-Sk for clue@ietf.org; Wed, 04 Feb 2015 21:48:56 +1100 Message-ID: <54D1F976.3090606@nteczone.com> Date: Wed, 04 Feb 2015 21:50:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <786615F3A85DF44AA2A76164A71FE1AC4B3831E5@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC4B3831E5@FR711WXCHMBA03.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Def. "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: Wed, 04 Feb 2015 10:50:38 -0000 I'm OK with your suggested definition. May we need to define WebRTC SCTPoDTLS association as a means of discussing the association? Regards, Christian On 3/02/2015 1:17 AM, Schwarz, Albrecht (Albrecht) wrote: > Like to propose a clarification/enhancement of the WebRTC DC definition in CLUE: > > draft-ietf-clue-datachannel-07 > 2. Conventions > ... > WebRTC Data Channel refers to a SCTPoDTLS association > [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media > data between two entities, according to the procedures in > [I-D.ietf-rtcweb-data-channel]. > > CLUE data channel refers to a WebRTC Data Channel > [I-D.ietf-rtcweb-data-channel] realization, with a specific set of > SCTP characteristics, with the purpose of transporting CLUE protocol > [I-D.ietf-clue-protocol] messages between two CLUE entities. > > > Issue: > the paragraph, as a summary of clause 6.4/draft-ietf-rtcweb-data-channel-13, seems to be a too high abstraction (because equating a "WebRTC DC" entity with a "SCTPoDTLS" association entity), however, the level of SCTP stream is missing. > > Like to suggest following enhancement: > > WebRTC Data Channel: represents an SCTP stream level object, constituted by a pair of one incoming SCTP stream and one outgoing SCTP stream (with identical SCTP stream identifier values), using the transport of a SCTPoDTLS association [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media data between two entities, according to the procedures in [I-D.ietf-rtcweb-data-channel]. > > Regards, > Albrecht > > PS > The definition of CLUE data channel is not affect because refering to the "realization" section in clause 6.4/draft-ietf-rtcweb-data-channel. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Feb 4 17:16:42 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D911A00FB for ; Wed, 4 Feb 2015 17:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3] 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 xanE0EvAxruL for ; Wed, 4 Feb 2015 17:16:38 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B231A00F7 for ; Wed, 4 Feb 2015 17:16:38 -0800 (PST) Received: from ppp118-209-97-104.lns20.mel4.internode.on.net ([118.209.97.104]:56041 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YJB1t-0006tY-5h for clue@ietf.org; Thu, 05 Feb 2015 12:14:49 +1100 Message-ID: <54D2C46E.1040700@nteczone.com> Date: Thu, 05 Feb 2015 12:16:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> In-Reply-To: <01d601d036ed$d501abf0$7f0503d0$@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: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 01:16:40 -0000 Hello Here are my last call comments: 1. Section 1 Introduction: I think it would be good to add a sentence to indicate that CLUE can be used in any multistream environment. It’s not just related to telepresence. 2. Section 4 1st para: "This section provides an overview of the functional elements defined in this document to represent a telepresence system". Like the above comment perhaps we could replace telepresence with multistream? The section talks about different types of systems, telepresence, webcam, multicast etc. CLUE can be applied to all of them. 3. Section 5 pg14 2nd para: "The Consumer in the Endpoint receives the information provided by the Provider, and can use it for two purposes" The paragraph only talks about using the information for constructing a Configure and for SDP. The provider can also use the information for rendering decisions. It would be good to clarify this. 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are optional in the consumer and that it is free to ignore the information. Whilst its true for the Advertisement I don't think this is generally true. It shouldn't ignore the Options message. 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, it means that whilst the Video Capture is not spatially related to any other Video Capture". Is this true? Captures in the one scene ARE spatially related. If the Area of capture is not included isn't the Provider just saying that it can't provide specific details on the relation? 6. Section 7.1.1.13: "This attribute is only applicable to video Captures and presentation streams with visual information." Could this also be applicable to audio captures? i.e. lyrics along with audio. 7. Section 7.2 Table 1: The table just lists "attributes" perhaps it should distinguish between "MCC attributes" and "MC attributes" to indicate the different scope. Also VCn should be aligned with the text below the table that indicates VC3. 8. Section 7.2.1.1 1st para: The actual number can be less "or equal to" the maximum. 9. Section 12.1.1 Pg45: I think it would be good to add "policy=SoundLevel" to MCC3 and MCC4 given that the descriptive text indicates this function. 10. Section 12.1.1 Pg48: I think we need to add some text to explain these parameters are not part of CLUE but are possible parameter that can be assigned to encodings via SDP? This is mentioned in section 12.1.2. Maybe we should move the text to the start of the example section so that it applies to all sections. 11. Section 12.3.1 Table14: It would be good to add "AllowSubset=True" to MCC1 Just make it clear that the Provider allowed to choose. 12. Section 12.3.2 Table17: Incorrect table title, should be "Advertisement set to Endpoint F". 13. Section 12.3.3 Table 20: Incorrect table title, should be "...from Endpoints E to G" 14. Section 7.2.14 Allow subset choice: Do we need to specify a default behaviour if this is not included? We specify in other cases e.g. area of capture what it means if not included. I've sent the purely editorial ones to the author. Regards, Christian On 23/01/2015 8:20 PM, Roni Even wrote: > > Hi, > > There were good reviews during the WGLC on the framework document. > > Mark updated the document to include all the issues that were > discussed in http://tools.ietf.org/html/draft-ietf-clue-framework-20 > > In order to verify that all concerns were addressed we will have a > short WGLC till *February 4^th * and in there are no more open issues > we will send the document to publication. > > Mark noted the following changes from 19 to 20: > > 1. Define term "CLUE" in introduction. > > 2. Add MCC attribute Allow Subset Choice. > > 3. Remove phrase about reducing SDP size, replace with > > potentially saving consumer resources. > > 4. Change example of a CLUE exchange that does not require SDP > > exchange. > > 5. Language attribute uses RFC5646. > > 6. Change Member person type to Attendee. Add Observer type. > > 7. Clarify DTLS/SRTP MUST be supported. > > 8. Change SHOULD NOT to MUST NOT regarding using xCard or > > description information for authorization decisions. > > 9. Clarify definition of Global View. > > 10. Refer to signaling doc regarding interoperating with a > > device that does not support CLUE. > > 11. Various minor editorial changes from working group last call > > feedback. > > 12. Capitalize defined terms. > > Thanks > > Roni Even > > CLUE co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Feb 5 09:19:05 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDDE1A07BC for ; Thu, 5 Feb 2015 09:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdSaHDdsyFYR for ; Thu, 5 Feb 2015 09:19:00 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9871A0404 for ; Thu, 5 Feb 2015 09:19:00 -0800 (PST) X-AuditID: 12074412-f79e46d0000036b4-d2-54d3a6035fa9 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 35.55.14004.306A3D45; Thu, 5 Feb 2015 12:18:59 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t15HIx84029534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 5 Feb 2015 12:18:59 -0500 Message-ID: <54D3A603.20407@alum.mit.edu> Date: Thu, 05 Feb 2015 12:18:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> In-Reply-To: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqMu87HKIwe9LVhb7T11mdmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bCjfsZC56IVfS2izQw9gp2MXJySAiYSOy80sYMYYtJXLi3 nq2LkYtDSOAyo8SFKVegnF9MEj8fLQOr4hXQlHi59gEriM0ioCqxonc+WJxNQEtizqH/LCC2 qECyxJqtk9gh6gUlTs58AhTn4BABsl9eAVssLGAn8fU/RImQgLnEtmV7GEFsTgELiS9X/4CV MwtYS3zbXQQSZhaQl9j+dg7zBEb+WUiGzkKomoWkagEj8ypGucSc0lzd3MTMnOLUZN3i5MS8 vNQiXTO93MwSvdSU0k2MkMAT2sG4/qTcIUYBDkYlHt4Huy+FCLEmlhVX5h5ilORgUhLlbZ5/ OUSILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+dZqAcb0piZVVqUT5MSpqDRUmc9+didT8hgfTE ktTs1NSC1CKYrAwHh5IEr95SoEbBotT01Iq0zJwShDQTByfIcC4pkeLUvJTUosTSkox4UCzG FwOjESTFA7T31xKQvcUFiblAUYjWU4yKUuK8AiBzBUASGaV5cGNh6eQVozjQl8K8XSDtPMBU BNf9CmgwE9Bg2YsXQAaXJCKkpBoYZ4pXTttlnjNvxv2NzRdMnDzlL2yo1Wc7cjRI40FTptuz edqzrkXVp8/5lP0g5On8GQ6hlpGX5nIs/HX82MK4zWnv/mhUqLBv2PFvygvrdZ7fuMPbOlju ixj0RGppmedL/15z6+ui3wfn9mZylyoJnm2bnMJxYNIG7ZBnNi7Sp6ZpqJpumLfJTYmlOCPR UIu5qDgRALOCh10CAwAA Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 17:19:03 -0000 I have just a few minor comments on this version: Section 7.1.1.4: The capture point of a static Capture MUST NOT move for the life of the conference. I don't think "conference" is the right word here. (The session might not be a conference.) Perhaps "CLUE session" would work, though it is not a defined term. Section 7.1.1.11: Again "conference is used where it might not be the right word. There could be only two endpoints in the call, even if there are several people at each end. And it is *possible* that there might be a Minute Taker even if there were only two people in the call. So again perhaps "session" or "CLUE session" would be better. Section 7.2: The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) in one Media Capture. The "temporally and/or spatially" works for video. Is that right for audio? I guess "temporally" still applies, but does "spatially"? Maybe it could if you have a stereo audio capture. But if you just mix the few loudest speakers, what do you call that? I don't have a suggestion about how to improve this. Does someone have a suggestion? If not then this may be as good as we can do. Thanks, Paul On 1/23/15 4:20 AM, Roni Even wrote: > Hi, > > There were good reviews during the WGLC on the framework document. > > Mark updated the document to include all the issues that were discussed > in http://tools.ietf.org/html/draft-ietf-clue-framework-20 > > In order to verify that all concerns were addressed we will have a short > WGLC till *February 4^th * and in there are no more open issues we will > send the document to publication. > > Mark noted the following changes from 19 to 20: > > 1. Define term "CLUE" in introduction. > > 2. Add MCC attribute Allow Subset Choice. > > 3. Remove phrase about reducing SDP size, replace with > > potentially saving consumer resources. > > 4. Change example of a CLUE exchange that does not require SDP > > exchange. > > 5. Language attribute uses RFC5646. > > 6. Change Member person type to Attendee. Add Observer type. > > 7. Clarify DTLS/SRTP MUST be supported. > > 8. Change SHOULD NOT to MUST NOT regarding using xCard or > > description information for authorization decisions. > > 9. Clarify definition of Global View. > > 10. Refer to signaling doc regarding interoperating with a > > device that does not support CLUE. > > 11. Various minor editorial changes from working group last call > > feedback. > > 12. Capitalize defined terms. > > Thanks > > Roni Even > > CLUE co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 5 14:43:22 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9E51A8757; Thu, 5 Feb 2015 14:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTKeKvSTj7U7; Thu, 5 Feb 2015 14:43:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B01EE1A87E3; Thu, 5 Feb 2015 14:43:07 -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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150205224307.12572.30915.idtracker@ietfa.amsl.com> Date: Thu, 05 Feb 2015 14:43:07 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-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: Thu, 05 Feb 2015 22:43:14 -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-03.txt Pages : 56 Date : 2015-02-05 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 across 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-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-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 Thu Feb 5 15:39:37 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E31A1F73 for ; Thu, 5 Feb 2015 15:39:26 -0800 (PST) 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 zZHOjeM0hnQb for ; Thu, 5 Feb 2015 15:39:25 -0800 (PST) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FD31A0004 for ; Thu, 5 Feb 2015 15:39:24 -0800 (PST) X-ASG-Debug-ID: 1423179561-05ce37732313d6b30001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id c0qyeuFzeDDwPYJX (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 06 Feb 2015 00:39:21 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.1.101] ([94.167.4.69]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id t15NdKGm029548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Feb 2015 00:39:20 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_65380F8A-7C09-4C14-B462-C9172014C571" Date: Fri, 6 Feb 2015 00:39:19 +0100 X-ASG-Orig-Subj: Updated CLUE protocol draft Message-Id: To: CLUE Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1423179561 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.14969 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [clue] Updated CLUE protocol draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 23:39:27 -0000 --Apple-Mail=_65380F8A-7C09-4C14-B462-C9172014C571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear all, we have just uploaded version -03 of the protocol draft. We believe we = have addressed most of the issues that were raised at last IETF in = Honolulu. The document should now be perfectly aligned with the = companion drafts produced by the WG (with special regard to the = signaling document). Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_65380F8A-7C09-4C14-B462-C9172014C571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear all,

we have just uploaded version -03 of the protocol draft. We = believe we have addressed most of the issues that were raised at last = IETF in Honolulu. The document should now be perfectly aligned with the = companion drafts produced by the WG (with special regard to the = signaling document).

Cheers,

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

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






= --Apple-Mail=_65380F8A-7C09-4C14-B462-C9172014C571-- From nobody Thu Feb 5 16:58:20 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342551A0097 for ; Thu, 5 Feb 2015 16:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU4RrtlelPkK for ; Thu, 5 Feb 2015 16:58:12 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1101A0067 for ; Thu, 5 Feb 2015 16:58:11 -0800 (PST) Received: from ppp118-209-225-165.lns20.mel8.internode.on.net ([118.209.225.165]:55506 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YJXDN-00021u-Ep for clue@ietf.org; Fri, 06 Feb 2015 11:56:09 +1100 Message-ID: <54D4119A.4030400@nteczone.com> Date: Fri, 06 Feb 2015 11:58:02 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: 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 - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 00:58:17 -0000 Hello In general the draft is pretty good. My comments: ------------ 1. General: I-D.ejzak- mmusic-data-channel-sdpneg has been made a WG draft . 2. Section 3.2.1.1: Given that the general feeling is that UDP will be more common than TCP do we want to make a recommendation on what transport CLUE endpoint should support in order to maximise interop? 3. Section 3.2.2 Heading: dcpmap -> dcmap 4. Section 3.2.2: Perhaps we should explicitly mention the data channel type used from [I-D.ietf-rtcweb-data-protocol] e.g. DATA_CHANNEL_RELIABLE. If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in Table 2 that the ordered, max-retr and max-time are not used due to the use of a reliable channel. 5. Section 3.3.5: Therefor -> Therefore 6. Section 3.3.6: Change "... in order to close data channel, a SCTP reset message [RFC6525] is sent to close the SCTP stream associated with the data channel". It should read better without the "," and the second "in order". 7. Section 5.1/5.2: The registries that need to be used for DCMAP and the WebRTC sub-protocol registry need to be sorted out. I'm not sure why two registries would be needed for essentially the same thing. 8. General: I don't think we can ship this off to the IESG until we can be sure that draft-ietf-mmusic-data-channel-sdpneg is stable. Regards, Christian On 31/01/2015 3:10 AM, Daniel Burnett wrote: > To all CLUE participants, > > Other than dependencies there do not seem to be any major outstanding > issues remaining for the data channel draft, so I am starting a WGLC > today. The end of this WGLC will be end of the day (wherever you are) > on Friday February 13. That gives two full weeks from today. > > If all is in order this will be the last review of this document by > the WG before it goes to the ADs and the IESG. Now is the time for > careful, thorough reviews of the full document. Thankfully, the > document is very short and easy to read since it largely references > other documents. Familiarity with both MMUSIC work and WebRTC data > channels is a plus but not required. > > To help in planning, please respond to this message if you plan to > submit a review. We can only move forward if we get reviews! > > And yes, I will be a doing a WGLC review of the draft myself :) > > -- dan > (for all the chairs) > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Feb 5 17:04:06 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FDB1A00E5 for ; Thu, 5 Feb 2015 17:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NolnJp5SNRMY for ; Thu, 5 Feb 2015 17:03:55 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72E71A038D for ; Thu, 5 Feb 2015 17:03:55 -0800 (PST) Received: from ppp118-209-225-165.lns20.mel8.internode.on.net ([118.209.225.165]:55699 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YJXIw-0002oB-Ga for clue@ietf.org; Fri, 06 Feb 2015 12:01:54 +1100 Message-ID: <54D412F3.4080900@nteczone.com> Date: Fri, 06 Feb 2015 12:03:47 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: 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: Subject: Re: [clue] Updated CLUE protocol draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 01:03:57 -0000 Hello Simon, I noticed the diff mechanism was removed. I didn't see anywhere that it was agreed to do this? If it was I didn't see how to handle the partial update mechanism moving forward. Regards, Christian On 6/02/2015 10:39 AM, Simon Pietro Romano wrote: > Dear all, > > we have just uploaded version -03 of the protocol draft. We believe we > have addressed most of the issues that were raised at last IETF in > Honolulu. The document should now be perfectly aligned with the > companion drafts produced by the WG (with special regard to the > signaling document). > > Cheers, > > Simon > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Feb 6 03:22:42 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983861A0141 for ; Fri, 6 Feb 2015 03:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfzJbzfxoe06 for ; Fri, 6 Feb 2015 03:22:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E97D1A0122 for ; Fri, 6 Feb 2015 03:22:36 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-83-54d4a3fae798 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.3D.24955.AF3A4D45; Fri, 6 Feb 2015 12:22:34 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0210.002; Fri, 6 Feb 2015 12:22:34 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1A== Date: Fri, 6 Feb 2015 11:22:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D695730@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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje6vxVdCDNa+MLH48r6RxWL/qcvM DkweS5b8ZPJYcX4mSwBTFJdNSmpOZllqkb5dAlfGvMcBBfuFKvom9jA1MB7k62Lk5JAQMJHY dX4pC4QtJnHh3nq2LkYuDiGBI4wSr64vZIRwFjFKTPywGyjDwcEmYCHR/U8bpEFEIFyiY9sV RhBbWCBF4v/f3awQ8VSJpU9PM0HYehLzujrAFrAIqEjcmfqHGcTmFfCVuHtzGlg9I9Di76fW gNUzC4hL3HoynwniIAGJJXvOM0PYohIvH/9jhbCVJFZsv8QIUa8jsWD3JzYIW1ti2cLXUPMF JU7OfMIygVF4FpKxs5C0zELSMgtJywJGllWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgUF/ cMtv1R2Ml984HmIU4GBU4uE10LsSIsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxqyCaSLrjwY1q6j6l1f03754daVnKMfaX6fKVfI27nzy7tmBwIzst8u1 Xd4xH/eO363wRsF6UYGfFNPpNJvM7f5qR38E+Zt4sh+/fTNEYs4W3reL2gJVb0xd+Sxj//ta 69UxzmWyCj8+vav8c05gtvcGH84nc05dPyXlHZr5OGe2WfD2qztsZyixFGckGmoxFxUnAgBm 2bkYWwIAAA== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 11:22:38 -0000 Hi Christian, Thanks for your comments. See inline. > 1. General: I-D.ejzak- mmusic-data-channel-sdpneg has been made a WG draf= t . If you look in the Reference section, I am actually referencing the draft-i= etf-mmusic version :) But, I did not change the reference tag. I can do that. ----------- > 2. Section 3.2.1.1: Given that the general feeling is that UDP will be mo= re common than TCP do we want to make a=20 > recommendation on what transport CLUE endpoint should support in order to= maximise interop? I guess we could say that TCP SHOULD only be used if needed for ICE purpose= . But, I'd like to make sure other are ok with such approach too. ----------- > 3. Section 3.2.2 Heading: dcpmap -> dcmap Will be fixed. ----------- > 4. Section 3.2.2: Perhaps we should explicitly mention the data channel t= ype used from [I-D.ietf-rtcweb-data-protocol] e.g.=20 > DATA_CHANNEL_RELIABLE. > If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in Ta= ble 2 that the=20 > ordered, max-retr and max-time are not used due to the use of a reliable = channel. I support that. ----------- > 5. Section 3.3.5: Therefor -> Therefore Will be fixed. ----------- > 6. Section 3.3.6: Change "... in order to close data channel, a SCTP rese= t=20 > message [RFC6525] is sent to close the SCTP stream associated with the=20 > data channel". It should read better without the "," and the second "in o= rder". Will be fixed. ----------- > 7. Section 5.1/5.2: The registries that need to be used for DCMAP and the= =20 > WebRTC sub-protocol registry need to be sorted out. I'm not sure why two = registries=20 > would be needed for essentially the same thing. I agree. I suggest to send an e-mail to the MMUSIC list regarding that, and= suggest that the same registry is used. ----------- > 8. General: I don't think we can ship this off to the IESG until we can b= e sure=20 > that draft-ietf-mmusic-data-channel-sdpneg is stable. My understanding is that we can do that, but that it will be kept in the RF= C Editor's Queue due to pending dependency. However, if we want to keep in in the WG, I have no problem with that. I hope the chairs and/or AD can give some guidance on this. Regards, Christer From nobody Fri Feb 6 08:01:42 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEA31A1E0B for ; Fri, 6 Feb 2015 08:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjvP-vtMwbMx for ; Fri, 6 Feb 2015 08:01:27 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id E741A1A1B69 for ; Fri, 6 Feb 2015 08:01:26 -0800 (PST) X-AuditID: 1207440e-f79bc6d000000c43-d1-54d4e555cf36 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id AF.FA.03139.555E4D45; Fri, 6 Feb 2015 11:01:25 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t16G1O0P025048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 6 Feb 2015 11:01:24 -0500 Message-ID: <54D4E554.5030502@alum.mit.edu> Date: Fri, 06 Feb 2015 11:01:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixO6iqBv69EqIwdTDwhb7T11mdmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8b7xtdsBeckKp5fe87WwLhGuIuRk0NCwESidV0zK4QtJnHh 3nq2LkYuDiGBy4wSH3u6oZxfTBIv5p1hB6niFdCW+PJqK5jNIqAqsfDfIUYQm01AS2LOof8s ILaoQLLEmq2ToOoFJU7OfAIU5+AQAbJfXhEECQsLpEgsO3uAGcQWEvCVWL+3B2wMp4CfxN9H lxlBypkFrCW+7S4CCTMLyEtsfzuHeQIj/ywkQ2chVM1CUrWAkXkVo1xiTmmubm5iZk5xarJu cXJiXl5qka6xXm5miV5qSukmRkjo8e1gbF8vc4hRgINRiYc3gfdKiBBrYllxZe4hRkkOJiVR 3uCNQCG+pPyUyozE4oz4otKc1OJDjBIczEoivD1LgXK8KYmVValF+TApaQ4WJXFetSXqfkIC 6YklqdmpqQWpRTBZGQ4OJQne2u1AjYJFqempFWmZOSUIaSYOTpDhXFIixal5KalFiaUlGfGg aIwvBsYjSIoHaO+nbSB7iwsSc4GiEK2nGBWlxCHmCoAkMkrz4MbCEsorRnGgL4V5f4K08wCT EVz3K6DBTECDF4M9VFySiJCSamA0+63Y+WC6sGBU1zzFzrQHRa4nKo56uZ1gbdkZec84rE5n /TXrheFbJbn+Sq5Mz5CV8uz7tny+/V0j2zsWq1bFmUsLyE6adrx1Yaa9RfuGmC3fF3odCN2R eUac+6nhgtU/pNZ982xI2ZRj+u/+ksrnDVtZnD7805/fqiSTMeFX5tSDe6+q2oUqsRRnJBpq MRcVJwIA1oT2gwMDAAA= Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:01:39 -0000 On 2/6/15 6:22 AM, Christer Holmberg wrote: > Hi Christian, > > Thanks for your comments. See inline. > >> 1. General: I-D.ejzak- mmusic-data-channel-sdpneg has been made a WG draft . > > If you look in the Reference section, I am actually referencing the draft-ietf-mmusic version :) > > But, I did not change the reference tag. I can do that. > > ----------- > >> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be more common than TCP do we want to make a >> recommendation on what transport CLUE endpoint should support in order to maximise interop? > > I guess we could say that TCP SHOULD only be used if needed for ICE purpose. > > But, I'd like to make sure other are ok with such approach too. Using TCP can cause bad head of line blocking issues for SCTP, between different streams. (Not so bad if there is only one stream in each direction and that is an ordered and reliable one.) I think the SHOULD would be a good idea. >> 3. Section 3.2.2 Heading: dcpmap -> dcmap > > Will be fixed. > > ----------- > >> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel type used from [I-D.ietf-rtcweb-data-protocol] e.g. >> DATA_CHANNEL_RELIABLE. >> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in Table 2 that the >> ordered, max-retr and max-time are not used due to the use of a reliable channel. > > I support that. > > ----------- > >> 5. Section 3.3.5: Therefor -> Therefore > > Will be fixed. > > ----------- > >> 6. Section 3.3.6: Change "... in order to close data channel, a SCTP reset >> message [RFC6525] is sent to close the SCTP stream associated with the >> data channel". It should read better without the "," and the second "in order". > > Will be fixed. > > ----------- > >> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and the >> WebRTC sub-protocol registry need to be sorted out. I'm not sure why two registries >> would be needed for essentially the same thing. > > I agree. I suggest to send an e-mail to the MMUSIC list regarding that, and suggest that the same registry is used. > > ----------- > >> 8. General: I don't think we can ship this off to the IESG until we can be sure >> that draft-ietf-mmusic-data-channel-sdpneg is stable. > > My understanding is that we can do that, but that it will be kept in the RFC Editor's Queue due to pending dependency. > > However, if we want to keep in in the WG, I have no problem with that. > > I hope the chairs and/or AD can give some guidance on this. There isn't much practical difference between the two ways. Holding it in the wg is fine as long as the work group is around and functioning and paying attention. Putting it in the queue puts it on "auto pilot", so we need not do anything more. I guess I would say that we can hold onto it until all the other drafts are ready for submission. At that point I am inclined to submit this one too. But we could do it sooner if people feel a need to claim completion of the milestone. Thanks, Paul From nobody Fri Feb 6 13:42:02 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD31A8876 for ; Fri, 6 Feb 2015 13:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYXAoH1bQXjs for ; Fri, 6 Feb 2015 13:41:57 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0795F1A8884 for ; Fri, 6 Feb 2015 13:41:29 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-66-54d5350793ba Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.C8.04484.70535D45; Fri, 6 Feb 2015 22:41:27 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0210.002; Fri, 6 Feb 2015 22:41:27 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1AAHpHwAAAUmAtA= Date: Fri, 6 Feb 2015 21:41:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D696604@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <54D4E554.5030502@alum.mit.edu> In-Reply-To: <54D4E554.5030502@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjS676dUQgycbLC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjyc1W9oKlwhWfpx1lbmD8y9fFyMkhIWAi cfpKJxuELSZx4d56IJuLQ0jgCKPE2wkvGCGcRYwSt85OZuli5OBgE7CQ6P6nDdIgIuApsePj FGYQW1ggReL/392sEPFUiaVPTzNB2FYS+/fMAFvAIqAi8freIxYQm1fAV+LIvDVgtpBAvsSm +8/YQcZzCuhIPPleBhJmBLrn+6k1YGOYBcQlbj2ZzwRxp4DEkj3nmSFsUYmXj/+xQthKEo1L nrBC1OtILNj9iQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFS brqRkV5qUWZycXF+nl5easkmRmCUHNzy22AH48vnjocYBTgYlXh4DfSuhAixJpYVV+YeYpTm YFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXGV1rwVDrkT5X9nHbvne3GH7+kO 303VjsqG/Y+suTdtUl+t8zswz2dZcrPWtLKiGb15r35oGpedEddj/7bpz0/PFeclLbb8WLvC +ZzCmUXvLdsPdhnG2FQwJDlP1fPPuZhpVF70IKLnwxb9zP6ln3ynGbaJukZ3f7FUUa+87Mv7 qTHhtei+X0osxRmJhlrMRcWJAM/NT3ZzAgAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 21:41:58 -0000 Hi, >>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will=20 >>> be more common than TCP do we want to make a recommendation on=20 >>> what transport CLUE endpoint should support in order to maximise intero= p? >> >> I guess we could say that TCP SHOULD only be used if needed for ICE purp= ose. >> >> But, I'd like to make sure other are ok with such approach too. > > Using TCP can cause bad head of line blocking issues for SCTP, between di= fferent=20 > streams. (Not so bad if there is only one stream in each direction and th= at is an=20 > ordered and reliable one.) > > I think the SHOULD would be a good idea. I can add some text. ...eventhough I think the issues with TCP (presented by Paul) should be des= cribed in the base WebRTC Data Channel draft, or in the SCTP over DTLS enca= psulation draft. But, as some of us know, those drafts don't say much (if anything) about TC= P to begin with... ... >>> 8. General: I don't think we can ship this off to the IESG until we=20 >>> can be sure that draft-ietf-mmusic-data-channel-sdpneg is stable. >> >> My understanding is that we can do that, but that it will be kept in the= RFC Editor's Queue due to pending dependency. >> >> However, if we want to keep in in the WG, I have no problem with that. >> >> I hope the chairs and/or AD can give some guidance on this. > > There isn't much practical difference between the two ways. Holding it in= the wg is fine as long as the work group is around and > functioning and p= aying attention. Putting it in the queue puts it on "auto pilot", so we nee= d not do anything more. > > I guess I would say that we can hold onto it until all the other drafts a= re ready for submission. At that point I am inclined to=20 > submit this one too. But we could do it sooner if people feel a need to c= laim completion of the milestone. Personally I think we can keep it in the working group at least until the o= ther drafts are ready for submission. Also, in addition to the SDP-NEG draft, the CLUE data channel draft is depe= nding on the WebRTC Data Channel draft and the SDP-SCTP drafts to be finali= zed, so it is probably going to take a while until we get an RFC number any= way. Finally, if there are any changes in other drafts, that affect the CLUE dat= a channel draft, I guess it is easier to make changes if the draft is in th= e working group. Regards, Christer From nobody Sat Feb 7 04:10:15 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5671A1B16 for ; Sat, 7 Feb 2015 04:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dSKQrma8z6c for ; Sat, 7 Feb 2015 04:09:10 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (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 B845A1A0141 for ; Sat, 7 Feb 2015 04:09:09 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id l61so18343580wev.8 for ; Sat, 07 Feb 2015 04:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=bYlleKHAbmGo357ieJmFuWXjZmjWROQv5ugg2x4eNCk=; b=ojeiKtv7/SQreh8+7kHSuCNc1AY+PtpML9/Uuti8D5LdWKlSv9ht5lYCed9yvUuTwu oDwOlt14tJZ7nAgr9KbfcAjapyTwiSzNGXRLk9+AuAJsuLIxuv6yypSznUVMHsz31vc+ 8rRk9+YoIAtQdTzCTjY/3zP0zfSzQsPZkfQ7Vz29/yZN64MLA3fu+Dcr0lYNx0r/aCYI KvkT2Hu5GKG0TWCL9QuTdJpf5McF7Q3+AbqqnoalSWXQQh0dzfY+TBUBmFfUixlESZQg hJ1M1y1EfpW1V2QWEVzELT0BjS33mn6IR3sBO3bHgY/RdccbMX4A4EtV2Wz3Cab3lKu7 nS4g== X-Received: by 10.180.212.113 with SMTP id nj17mr13599052wic.54.1423310948576; Sat, 07 Feb 2015 04:09:08 -0800 (PST) Received: from RoniE (bzq-79-183-57-46.red.bezeqint.net. [79.183.57.46]) by mx.google.com with ESMTPSA id bd8sm7366228wjc.21.2015.02.07.04.09.06 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 07 Feb 2015 04:09:07 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" Date: Sat, 7 Feb 2015 14:09:02 +0200 Message-ID: <0a0801d042ce$de7b40a0$9b71c1e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A09_01D042DF.A20410A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBCzqsLgv+o/GW3Q2myVxVJYCE4iQ== Content-Language: en-us Archived-At: Cc: clue@ietf.org Subject: [clue] end of short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 12:09:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A09_01D042DF.A20410A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There were comments from Christian and Paul. Thanks for reviewing the document. Mark can you please address them so that we can finish the document Thanks Roni Even CLUE co-chair ------=_NextPart_000_0A09_01D042DF.A20410A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There were comments from = Christian and Paul. Thanks for reviewing the = document.

Mark can you please address them so that we can = finish the document

Thanks

Roni = Even

CLUE co-chair

 

------=_NextPart_000_0A09_01D042DF.A20410A0-- From nobody Sun Feb 8 06:19:07 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C81A904E for ; Sun, 8 Feb 2015 06:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRqBoOLPGxSh for ; Sun, 8 Feb 2015 06:19:02 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC93F1A9063 for ; Sun, 8 Feb 2015 06:19:01 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-41-54d7705398ff Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5A.7F.04076.35077D45; Sun, 8 Feb 2015 15:18:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Sun, 8 Feb 2015 15:18:59 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLg Date: Sun, 8 Feb 2015 14:18:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D695730@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW5wwfUQg4W/DS2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJVx9YdaQT9/RcfEB6wNjL08XYwcHBICJhLr Z4t3MXICmWISF+6tZ+ti5OIQEjjCKHF+Vj8jhLOYUeL97bXsIA1sAhYS3f+0QRpEBMIlOrZd YQSxhQVSJP7/3c0KEU+VWPr0NBOEbSRx5E4fG4jNIqAi8eJyGzOIzSvgK3Fy8gmweiEge/3e HrA5nAJ+En8fXQazGYEO+n5qDdgcZgFxiVtP5jNBHCogsWTPeWYIW1Ti5eN/rBC2ksTaw9tZ IOp1JBbs/sQGYWtLLFv4GmqvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93I SC+1KDO5uDg/Ty8vtWQTIzBGDm75bbWD8eBzx0OMAhyMSjy8GxyvhwixJpYVV+YeYpTmYFES 57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdHgWOmbhty69JajeW9kdIo2Zn2vn3jJ d9sZiRddCY8D0uedzU5+Y3K/YSHLJdXO/RxvNC59FnQMu+7PdJmnbdl2Z38RpgNLzerTDzf1 REUq1byZsVvIcje7+TehX+smJPHkOqkazyqfbHf66ibOB//sjPWeFx6uCNieUMG53S7P/W5F fkTZFSWW4oxEQy3mouJEANpaz+RyAgAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2015 14:19:04 -0000 Hi, >> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be=20 >> more common than TCP do we want to make a recommendation on=20 >> what transport CLUE endpoint should support in order to maximise interop= ? > > I guess we could say that TCP SHOULD only be used if needed for ICE purpo= se. > > But, I'd like to make sure other are ok with such approach too. What about adding the following text: "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association used= to realize the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value), un= less=20 the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] i= s used and=20 the ICE procedures determines that TCP transport is required." ----------- >> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel = type used from [I-D.ietf-rtcweb-data-protocol] e.g.=20 >> DATA_CHANNEL_RELIABLE. >> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in=20 >> Table 2 that the ordered, max-retr and max-time are not used due to the = use of a reliable channel. > > I support that. What about adding the following text: "NOTE: As CLUE entities are required to use ordered SCTP message delivery, with full reliability, according to the procedures in [I-D.ietf-mmusic-dat= a-channel-sdpneg] the ordered, max-retr and max-time attribute parameters are not used when= =20 negotiating CLUE data channels." ----------- >> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and=20 >> the WebRTC sub-protocol registry need to be sorted out. I'm not sure=20 >> why two registries would be needed for essentially the same thing. > > I agree. I suggest to send an e-mail to the MMUSIC list regarding that, a= nd suggest that the same registry is used. I sent an e-mail regarding this to the MMUSIC list.=20 Regards, Christer From nobody Mon Feb 9 08:11:31 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77E1A1A62 for ; Mon, 9 Feb 2015 08:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQY8jl3c1-Wr for ; Mon, 9 Feb 2015 08:06:32 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC371A1A5C for ; Mon, 9 Feb 2015 08:06:31 -0800 (PST) Received: from [216.82.254.19] by server-16.bemta-7.messagelabs.com id 0F/D9-02765-60BD8D45; Mon, 09 Feb 2015 16:06:30 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-96.messagelabs.com!1423497952!13615696!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 937 invoked from network); 9 Feb 2015 16:05:52 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 9 Feb 2015 16:05:52 -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; Mon, 9 Feb 2015 08:06:09 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 9 Feb 2015 08:06:15 -0800 From: "Duckworth, Mark" To: Roni Even Date: Mon, 9 Feb 2015 08:05:50 -0800 Thread-Topic: end of short WGLC on draft-ietf-clue-framework-20 Thread-Index: AdBCzqsLgv+o/GW3Q2myVxVJYCE4iQBs4rWg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BF38@CRPMBOXPRD08.polycom.com> References: <0a0801d042ce$de7b40a0$9b71c1e0$@gmail.com> In-Reply-To: <0a0801d042ce$de7b40a0$9b71c1e0$@gmail.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_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BF38CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] end of short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:06:38 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BF38CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I'll review comments from Christian and Paul and respond this week. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Saturday, February 07, 2015 7:09 AM To: Duckworth, Mark Cc: clue@ietf.org Subject: end of short WGLC on draft-ietf-clue-framework-20 Hi, There were comments from Christian and Paul. Thanks for reviewing the docum= ent. Mark can you please address them so that we can finish the document Thanks Roni Even CLUE co-chair --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BF38CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I’ll review comments from Christian and Paul and r= espond this week.

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Saturday, February 07, 2015 7:09 AM
To: Duckworth, Mark
C= c: clue@ietf.org
Subject: end of short WGLC on draft-ietf-clu= e-framework-20

&= nbsp;

Hi,<= /o:p>

There we= re comments from Christian and Paul. Thanks for reviewing the document.

Mark c= an you please address them so that we can finish the document

Thanks

Roni Even

CLUE = co-chair

 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BF38CRPMBOXPRD08p_-- From nobody Mon Feb 9 12:35:08 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5001A1F70 for ; Mon, 9 Feb 2015 11:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3rKt7hUWssL for ; Mon, 9 Feb 2015 11:52:59 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4C41A1F00 for ; Mon, 9 Feb 2015 11:52:42 -0800 (PST) Received: from [216.82.249.212] by server-17.bemta-12.messagelabs.com id 9D/0C-02755-90019D45; Mon, 09 Feb 2015 19:52:41 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-219.messagelabs.com!1423511546!8555050!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20390 invoked from network); 9 Feb 2015 19:52:26 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-14.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 9 Feb 2015 19:52:26 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 9 Feb 2015 11:52:50 -0800 From: "Duckworth, Mark" To: Christer Holmberg , Christian Groves , "clue@ietf.org" Date: Mon, 9 Feb 2015 11:52:25 -0800 Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAD4BkxA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB1@CRPMBOXPRD08.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments 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, 09 Feb 2015 19:53:01 -0000 I agree with Christer's proposed new text for items 2 and 4 below. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Sunday, February 08, 2015 9:19 AM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 Februa= ry - > Christian's comments >=20 >=20 > Hi, >=20 > >> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be > >> more common than TCP do we want to make a recommendation on > >> what transport CLUE endpoint should support in order to maximise > interop? > > > > I guess we could say that TCP SHOULD only be used if needed for ICE > purpose. > > > > But, I'd like to make sure other are ok with such approach too. >=20 > What about adding the following text: >=20 > "CLUE entities SHOULD NOT use the transport the SCTPoDTLS > association used to realize > the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto > value), unless > the the Interactive Connectivity Establishment (ICE) mechanism > [RFC5245] is used and > the ICE procedures determines that TCP transport is required." >=20 > ----------- >=20 > >> 4. Section 3.2.2: Perhaps we should explicitly mention the data channe= l > type used from [I-D.ietf-rtcweb-data-protocol] e.g. > >> DATA_CHANNEL_RELIABLE. > >> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in > >> Table 2 that the ordered, max-retr and max-time are not used due to th= e > use of a reliable channel. > > > > I support that. >=20 > What about adding the following text: >=20 > "NOTE: As CLUE entities are required to use ordered SCTP message > delivery, > with full reliability, according to the procedures in [I-D.ietf-mmusic- > data-channel-sdpneg] > the ordered, max-retr and max-time attribute parameters are not > used when > negotiating CLUE data channels." >=20 > ----------- >=20 > >> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and > >> the WebRTC sub-protocol registry need to be sorted out. I'm not sure > >> why two registries would be needed for essentially the same thing. > > > > I agree. I suggest to send an e-mail to the MMUSIC list regarding that,= and > suggest that the same registry is used. >=20 > I sent an e-mail regarding this to the MMUSIC list. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Feb 9 12:42:19 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179D81A1F1D for ; Mon, 9 Feb 2015 12:01:42 -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 xPQ_E3D8zMcC for ; Mon, 9 Feb 2015 12:01:38 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4C31A1EFD for ; Mon, 9 Feb 2015 12:01:38 -0800 (PST) Received: from [216.82.241.100] by server-17.bemta-8.messagelabs.com id 37/B2-02755-12219D45; Mon, 09 Feb 2015 20:01:37 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-220.messagelabs.com!1423512096!14628410!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28501 invoked from network); 9 Feb 2015 20:01:37 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 9 Feb 2015 20:01:37 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 9 Feb 2015 12:01:52 -0800 From: "Duckworth, Mark" To: "Christer Holmberg (christer.holmberg@ericsson.com)" , "clue@ietf.org" Date: Mon, 9 Feb 2015 12:01:34 -0800 Thread-Topic: WGLC comments on clue-datachannel-07 Thread-Index: AdBEoxq66BQiebcUQ82B9xGhBaL+6A== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5@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_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] WGLC comments on clue-datachannel-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, 09 Feb 2015 20:01:42 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can't find it documented. If it does not apply to the CLUE d= ata channel, it would be good to say so. 3.3.2 - "A CLUE entity MUST NOT use the partial reliability and limited ret= ransmission extensions defined in [RFC3758]." Should this be more specific= , in just limiting it for the CLUE data channel, and not limit it for any o= ther WebRTC Data Channels that might be used for other purposes? Maybe "A = CLUE entity MUST NOT use the partial reliability and limited retransmission= extensions defined in [RFC3758], for the CLUE data channel." Or perhaps m= ore simply "A CLUE data channel MUST NOT use the partial reliability and li= mited retransmission extensions defined in [RFC3758]." 3.3.3 - "A CLUE entity MUST use the ordered delivery SCTP service, as descr= ibed in section 6.6 of [RFC4960]." Same comment as above, should this be li= mited to just the CLUE data channel? Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The document loo= ks good, I have only a couple minor suggestions.

 

draft-ietf-rtcweb-data-c= hannel section 6.4 says each data channel has a priority attribute.  D= oes this attribute apply to reliable messages, or only unreliable?  I = can’t find it documented.  If it does not apply to the CLUE data= channel, it would be good to say so.

 

3.3.2 – “A CLUE entity = MUST NOT use the partial reliability and limited retransmission extensions = defined in [RFC3758].”  Should this be more specific, in just li= miting it for the CLUE data channel, and not limit it for any other WebRTC = Data Channels that might be used for other purposes?  Maybe “A C= LUE entity MUST NOT use the partial reliability and limited retransmission = extensions defined in [RFC3758], for the CLUE data channel.”  Or= perhaps more simply “A CLUE data channel MUST NOT use the partial re= liability and limited retransmission extensions defined in [RFC3758].”= ;

 

3.3.3 – “A CLUE entity MUST use the ordered delivery SCTP s= ervice, as described in section 6.6 of [RFC4960].” Same comment as ab= ove, should this be limited to just the CLUE data channel?

 

Regards,<= /o:p>

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5CRPMBOXPRD08p_-- From nobody Mon Feb 9 12:43:40 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098BB1A8881 for ; Mon, 9 Feb 2015 12:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0GQBunv0kpF for ; Mon, 9 Feb 2015 12:05:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358AB1A8825 for ; Mon, 9 Feb 2015 12:05:07 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-bc-54d912f0301e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.D2.04076.0F219D45; Mon, 9 Feb 2015 21:05:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0210.002; Mon, 9 Feb 2015 21:05:04 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: WGLC comments on clue-datachannel-07 - Mark's comments Thread-Index: AdBEo5B5/RiwabFpR+i6+V35hy9nBg== Date: Mon, 9 Feb 2015 20:05:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6BC829@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.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6BC829ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje4HoZshBjtPmFvsP3WZ2WLdkafM DkweS5b8ZPJ48UApgCmKyyYlNSezLLVI3y6BK+Phjp8sBVstK+73PWVtYFxh1MXIySEhYCJx YOJ2VghbTOLCvfVsXYxcHEICRxglTh1ewQjhLGaUuPjqN3MXIwcHm4CFRPc/bZAGEYFQidUz N7GA2MICzhINnbtZIOIuEvOWX2cEKRcR0JP4/jAGJMwioCLxY/1iRhCbV8BX4trtO2A2I9De 76fWMIHYzALiEreezGeCuEdAYsme88wQtqjEy8f/oO5Uklh0+zNUfb7Eyuv9rBAzBSVOznzC MoFRaBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGeml FmUmFxfn5+nlpZZsYgTGyMEtv612MB587niIUYCDUYmHd4PSjRAh1sSy4srcQ4zSHCxK4rx2 xodChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOS3lbfmBuqfcTdpczZ6/uOF0YXHa1VNTa fOMVmQlCS9rfijmu0vZpb3fJ0RCfK3v85hex9KpTF5Wl1snd9/Gs5i/jVMlhc1l6u3Xv12mv /fWv1hgzbpOTtNS/xzJh1+6NEf8bXqvuj526iLcvsp4hS3b9jj0aT0qOHCwtfHpqgmyNf8Sk bQJKLMUZiYZazEXFiQB+lGcScgIAAA== Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments 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, 09 Feb 2015 20:05:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6BC829ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, Thanks for your comments! I agree with your suggestion to make it clear that the text is talking abou= t the CLUE data channel. Regards, Christer From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02 To: Christer Holmberg; clue@ietf.org Subject: WGLC comments on clue-datachannel-07 The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can't find it documented. If it does not apply to the CLUE d= ata channel, it would be good to say so. 3.3.2 - "A CLUE entity MUST NOT use the partial reliability and limited ret= ransmission extensions defined in [RFC3758]." Should this be more specific= , in just limiting it for the CLUE data channel, and not limit it for any o= ther WebRTC Data Channels that might be used for other purposes? Maybe "A = CLUE entity MUST NOT use the partial reliability and limited retransmission= extensions defined in [RFC3758], for the CLUE data channel." Or perhaps m= ore simply "A CLUE data channel MUST NOT use the partial reliability and li= mited retransmission extensions defined in [RFC3758]." 3.3.3 - "A CLUE entity MUST use the ordered delivery SCTP service, as descr= ibed in section 6.6 of [RFC4960]." Same comment as above, should this be li= mited to just the CLUE data channel? Regards, Mark --_000_7594FB04B1934943A5C02806D1A2204B1D6BC829ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,

 

Thanks for your comments!

 

I agree with your suggestion to make it clear that the text is talking= about the CLUE data channel.

 

Regards,

 

Christer

 

From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: 09 February 2015 22:02
To: Christer Holmberg; clue@ietf.org
Subject: WGLC comments on clue-datachannel-07

 

The document looks good, I have= only a couple minor suggestions.

 

draft-ietf-rtcweb-data-channel = section 6.4 says each data channel has a priority attribute.  Does thi= s attribute apply to reliable messages, or only unreliable?  I canR= 17;t find it documented.  If it does not apply to the CLUE data channel, it would be good to say so.

 

3.3.2 – “A CLUE ent= ity MUST NOT use the partial reliability and limited retransmission extensi= ons defined in [RFC3758].”  Should this be more specific, in jus= t limiting it for the CLUE data channel, and not limit it for any other WebRTC Data Channels that might be used for other purposes? = ; Maybe “A CLUE entity MUST NOT use the partial reliability and limit= ed retransmission extensions defined in [RFC3758], for the CLUE data channe= l.”  Or perhaps more simply “A CLUE data channel MUST NOT use the partial reliability and limited retransmission extensions= defined in [RFC3758].”

 

3.3.3 – “A CLUE ent= ity MUST use the ordered delivery SCTP service, as described in section 6.6= of [RFC4960].” Same comment as above, should this be limited to just= the CLUE data channel?

 

Regards,

Mark

--_000_7594FB04B1934943A5C02806D1A2204B1D6BC829ESESSMB209erics_-- From nobody Mon Feb 9 20:42:01 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276971A8714 for ; Mon, 9 Feb 2015 20:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMNuK7BBx5n6 for ; Mon, 9 Feb 2015 20:41:58 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A4B1A03FF for ; Mon, 9 Feb 2015 20:41:58 -0800 (PST) Received: from 212-147-18-59.fix.access.vtx.ch ([212.147.18.59]:1993 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YL2dh-00014C-W0; Tue, 10 Feb 2015 15:41:34 +1100 Message-ID: <54D98C0B.9040307@nteczone.com> Date: Tue, 10 Feb 2015 15:41:47 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments 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, 10 Feb 2015 04:42:00 -0000 Hello Christer, On 9/02/2015 1:18 AM, Christer Holmberg wrote: > Hi, > >>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be >>> more common than TCP do we want to make a recommendation on >>> what transport CLUE endpoint should support in order to maximise interop? >> I guess we could say that TCP SHOULD only be used if needed for ICE purpose. >> >> But, I'd like to make sure other are ok with such approach too. > What about adding the following text: > > "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association used to realize > the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless > the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used and > the ICE procedures determines that TCP transport is required." [CNG] I think there's one "the" too many in the first line. Should it read "CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize..."? Regards, Christian > > ----------- > >>> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel type used from [I-D.ietf-rtcweb-data-protocol] e.g. >>> DATA_CHANNEL_RELIABLE. >>> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in >>> Table 2 that the ordered, max-retr and max-time are not used due to the use of a reliable channel. >> I support that. > What about adding the following text: > > "NOTE: As CLUE entities are required to use ordered SCTP message delivery, > with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg] > the ordered, max-retr and max-time attribute parameters are not used when > negotiating CLUE data channels." > > ----------- > >>> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and >>> the WebRTC sub-protocol registry need to be sorted out. I'm not sure >>> why two registries would be needed for essentially the same thing. >> I agree. I suggest to send an e-mail to the MMUSIC list regarding that, and suggest that the same registry is used. > I sent an e-mail regarding this to the MMUSIC list. > > Regards, > > Christer > From nobody Mon Feb 9 23:24:15 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A809D1A0053 for ; Mon, 9 Feb 2015 23:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsdpRKswNwO2 for ; Mon, 9 Feb 2015 23:24:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DB01A005F for ; Mon, 9 Feb 2015 23:24:10 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-db-54d9b21767cc Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.8A.04076.712B9D45; Tue, 10 Feb 2015 08:24:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Tue, 10 Feb 2015 08:24:07 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAE5zxYAAB72MoA== Date: Tue, 10 Feb 2015 07:24:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6C05D5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54D98C0B.9040307@nteczone.com> In-Reply-To: <54D98C0B.9040307@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja74ppshBnsfWFt8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugStj58VJTAWv2Svu3Z/O1MA4j62LkZNDQsBE 4tf92VC2mMSFe+uBbC4OIYEjjBJtc88yQThLGCUmTL3E3sXIwcEmYCHR/U8bpEFEIFyiY9sV RhBbWCBF4v/f3awQ8VSJpU9PM0HYThJvuo6xgNgsAqoSj36/ZAIZwyvgK/FhuRvE+M2MEl0r toHN4RTQkejd+hSslxHooO+n1oDZzALiEreezGeCOFRAYsme88wQtqjEy8f/WCFsRYmPr/Yx QtTrSCzY/YkNwtaWWLbwNVg9r4CgxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg3 3chIL7UoM7m4OD9PLy+1ZBMjME4ObvlttYPx4HPHQ4wCHIxKPLwGJTdDhFgTy4orcw8xSnOw KInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAGFboLH9a/qXb/ClBi80fv1NWuKRQ 2tcl6XTA28nCVtv0UPG+Nbz3Z6k2u8qqOT+68NlUU6hvBpv++YOzy7/PWx+54MbROaYfWC7u Walps3Kv70TXBdOfzXhjeWTmol/V7S+Tk4pnnHi3vK3Hbdayeu/o+aVTVty2fbHrxdxPXV1F gdI/hd2WXlViKc5INNRiLipOBAAuxILFdAIAAA== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments 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, 10 Feb 2015 07:24:12 -0000 Hi, >>>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will=20 >>>> be more common than TCP do we want to make a recommendation on what=20 >>>> transport CLUE endpoint should support in order to maximise interop? >>> I guess we could say that TCP SHOULD only be used if needed for ICE pur= pose. >>> >>> But, I'd like to make sure other are ok with such approach too. >> What about adding the following text: >> >> "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association u= sed to realize >> the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value),= unless >> the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245= ] is used and >> the ICE procedures determines that TCP transport is required." > [CNG] I think there's one "the" too many in the first line. Should it rea= d "CLUE entities SHOULD NOT transport the SCTPoDTLS association used to rea= lize..."? Correct. I'll fix that. Regards, Christer From nobody Mon Feb 9 23:51:50 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66171A016C for ; Mon, 9 Feb 2015 23:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1iDZaacQ5Gx for ; Mon, 9 Feb 2015 23:51:45 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61DA31A00C2 for ; Mon, 9 Feb 2015 23:51:44 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-9e-54d9b88e01ae Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 58.A4.04484.E88B9D45; Tue, 10 Feb 2015 08:51:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Tue, 10 Feb 2015 08:51:42 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: WGLC comments on clue-datachannel-07 - Mark's comments Thread-Index: AdBEo5B5/RiwabFpR+i6+V35hy9nBgAYjZpQ Date: Tue, 10 Feb 2015 07:51:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6C076C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6BC829@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6BC829@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6C076CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+JvjW7fjpshBhsf61vsP3WZ2WLdkafM DkweS5b8ZPJ48UApgCmKyyYlNSezLLVI3y6BK+PyvRa2gn6/in9rHrM2MC536WLk5JAQMJHY MHMbM4QtJnHh3nq2LkYuDiGBI4wSDy8+YYJwljBK7Jy8HqiKg4NNwEKi+582SIOIQKjE6pmb WEBsYQFniYbO3SwQcReJecuvM0LYRhIvvqxgArFZBFQl/jxsZgWxeQV8JfovLAQbKQRk/z5m ARLmFPCTOH30GFgJI9A930+tAWtlFhCXuPVkPhPEnQISS/ach7pZVOLl43+sELaixMdX+xgh 6vMlvnXdYIJYJShxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZf wMi+ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwpg5u+W2wg/Hlc8dDjAIcjEo8vAYlN0OE WBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY93mi1pqYmPcu 1y0jn3uHblCwKTT+W7Cv5vi1efI14tddec7u0/OddEFzLU/54mM72E7y9XG5/bRWlXu/U7jZ /WmbXdtSoQj/HStE/7u6LivhbJPcEs42/5BCr9ICzpea8Sa+57d9PHKiQ247n1iqpU2gcmR7 3xIJPemQPBvfW9uU9hx58VWJpTgj0VCLuag4EQDIeb5YigIAAA== Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments 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, 10 Feb 2015 07:51:48 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6C076CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Regarding the priority attribute, my understanding is that it is only appli= cable to partial reliability (there is no priority flag/parameter in core S= CTP, as far as I know). Assuming my understanding is correct, I don't think we need to say anything= , because we already say that partial reliability is not used. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 9. helmikuuta 2015 22:05 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments Hi Mark, Thanks for your comments! I agree with your suggestion to make it clear that the text is talking abou= t the CLUE data channel. Regards, Christer From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02 To: Christer Holmberg; clue@ietf.org Subject: WGLC comments on clue-datachannel-07 The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can't find it documented. If it does not apply to the CLUE d= ata channel, it would be good to say so. 3.3.2 - "A CLUE entity MUST NOT use the partial reliability and limited ret= ransmission extensions defined in [RFC3758]." Should this be more specific= , in just limiting it for the CLUE data channel, and not limit it for any o= ther WebRTC Data Channels that might be used for other purposes? Maybe "A = CLUE entity MUST NOT use the partial reliability and limited retransmission= extensions defined in [RFC3758], for the CLUE data channel." Or perhaps m= ore simply "A CLUE data channel MUST NOT use the partial reliability and li= mited retransmission extensions defined in [RFC3758]." 3.3.3 - "A CLUE entity MUST use the ordered delivery SCTP service, as descr= ibed in section 6.6 of [RFC4960]." Same comment as above, should this be li= mited to just the CLUE data channel? Regards, Mark --_000_7594FB04B1934943A5C02806D1A2204B1D6C076CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Regarding the priority= attribute, my understanding is that it is only applicable to partial relia= bility (there is no priority flag/parameter in core SCTP, as far as I know)= .

 

Assuming my understand= ing is correct, I don’t think we need to say anything, because we alr= eady say that partial reliability is not used.

 

Regards,

 

Christer

 

 

From: clue [ma= ilto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 9. helmikuuta 2015 22:05
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's co= mments

 

Hi Mark= ,

&n= bsp;

Thanks = for your comments!

&n= bsp;

I agree= with your suggestion to make it clear that the text is talking about the C= LUE data channel.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

 

From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: 09 February 2015 22:02
To: Christer Holmberg; clue@ietf.or= g
Subject: WGLC comments on clue-datachannel-07

 

The document looks good, I have only a couple minor = suggestions.

 

draft-ietf-rtcweb-data-channel section 6.4 says each= data channel has a priority attribute.  Does this attribute apply to = reliable messages, or only unreliable?  I can’t find it document= ed.  If it does not apply to the CLUE data channel, it would be good to say so.

 

3.3.2 – “A CLUE entity MUST NOT use the = partial reliability and limited retransmission extensions defined in [RFC37= 58].”  Should this be more specific, in just limiting it for the= CLUE data channel, and not limit it for any other WebRTC Data Channels that might be used for other purposes?  Maybe “A = CLUE entity MUST NOT use the partial reliability and limited retransmission= extensions defined in [RFC3758], for the CLUE data channel.”  O= r perhaps more simply “A CLUE data channel MUST NOT use the partial reliability and limited retransmission extensions defined in [= RFC3758].”

 

3.3.3 – “A CLUE entity MUST use the orde= red delivery SCTP service, as described in section 6.6 of [RFC4960].”= Same comment as above, should this be limited to just the CLUE data channe= l?

 

Regards,

Mark

--_000_7594FB04B1934943A5C02806D1A2204B1D6C076CESESSMB209erics_-- From nobody Tue Feb 10 06:46:54 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D41A701F for ; Tue, 10 Feb 2015 06:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldCa4kD9k-HE for ; Tue, 10 Feb 2015 06:46:49 -0800 (PST) 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 668CE1A7033 for ; Tue, 10 Feb 2015 06:46:42 -0800 (PST) Received: from [216.82.254.19] by server-9.bemta-7.messagelabs.com id A9/EE-02994-1D91AD45; Tue, 10 Feb 2015 14:46:41 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-15.tower-96.messagelabs.com!1423579600!12326275!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12727 invoked from network); 10 Feb 2015 14:46:40 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-15.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 10 Feb 2015 14:46:40 -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, 10 Feb 2015 06:47:04 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Tue, 10 Feb 2015 06:47:04 -0800 From: "Duckworth, Mark" To: Christer Holmberg , "clue@ietf.org" Date: Tue, 10 Feb 2015 06:46:37 -0800 Thread-Topic: WGLC comments on clue-datachannel-07 - Mark's comments Thread-Index: AdBEo5B5/RiwabFpR+i6+V35hy9nBgAYjZpQAA52uQA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023@CRPMBOXPRD08.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1D6BC829@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6C076C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6C076C@ESESSMB209.ericsson.se> 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_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments 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, 10 Feb 2015 14:46:52 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I couldn't find any documentation about how this priority attribute is used= . If it really is for partial reliability only, then I agree with you that= the CLUE document doesn't need to say anything more. But I can't find thi= s stated anywhere in draft-ietf-rtcweb-data-channel or any other draft. Wo= uld it be safer to just say it doesn't apply in the CLUE data channel docum= ent? Mark From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 10, 2015 2:52 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments Hi, Regarding the priority attribute, my understanding is that it is only appli= cable to partial reliability (there is no priority flag/parameter in core S= CTP, as far as I know). Assuming my understanding is correct, I don't think we need to say anything= , because we already say that partial reliability is not used. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 9. helmikuuta 2015 22:05 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments Hi Mark, Thanks for your comments! I agree with your suggestion to make it clear that the text is talking abou= t the CLUE data channel. Regards, Christer From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02 To: Christer Holmberg; clue@ietf.org Subject: WGLC comments on clue-datachannel-07 The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can't find it documented. If it does not apply to the CLUE d= ata channel, it would be good to say so. 3.3.2 - "A CLUE entity MUST NOT use the partial reliability and limited ret= ransmission extensions defined in [RFC3758]." Should this be more specific= , in just limiting it for the CLUE data channel, and not limit it for any o= ther WebRTC Data Channels that might be used for other purposes? Maybe "A = CLUE entity MUST NOT use the partial reliability and limited retransmission= extensions defined in [RFC3758], for the CLUE data channel." Or perhaps m= ore simply "A CLUE data channel MUST NOT use the partial reliability and li= mited retransmission extensions defined in [RFC3758]." 3.3.3 - "A CLUE entity MUST use the ordered delivery SCTP service, as descr= ibed in section 6.6 of [RFC4960]." Same comment as above, should this be li= mited to just the CLUE data channel? Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I couldn’t find any documentation about how this priori= ty attribute is used.  If it really is for partial reliability only, t= hen I agree with you that the CLUE document doesn’t need to say anyth= ing more.  But I can’t find this stated anywhere in draft-ietf-rtcweb-data-channel or any other draft.=   Would it be safer to just say it doesn’t apply in the CLUE dat= a channel document?

 

Mark=

 

From: Christer Holmb= erg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, Febru= ary 10, 2015 2:52 AM
To: Duckworth, Mark; clue@ietf.org
Sub= ject: RE: WGLC comments on clue-datachannel-07 - Mark's comments

 

Hi,

 

<= p class=3DMsoNormal>Regarding the priority at= tribute, my understanding is that it is only applicable to partial reliabil= ity (there is no priority flag/parameter in core SCTP, as far as I know).

 

= Assuming my understanding is correct, I don’t think we need to say an= ything, because we already say that partial reliability is not used.

&nbs= p;

Regar= ds,

 

Christer

 

 

Fr= om: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Hol= mberg
Sent: 9. helmikuuta 2015 22:05
To: Duckworth, Mar= k; clue@ietf.org
Subject: Re: [clue] WGLC comments on clue-datach= annel-07 - Mark's comments

 

Hi Mark,

 

Thanks for your comment= s!

 

I agree with your suggestion to make it clear= that the text is talking about the CLUE data channel.

 = ;

Regards,

 

= Christer

 

From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: 09 February= 2015 22:02
To: Christer Holmberg; clue@ietf.org
Subject: WGLC comments on clue-datachannel-0= 7

&n= bsp;

The document looks good, I have o= nly a couple minor suggestions.

&nb= sp;

draft-ietf-rtcweb-data-channel section 6.= 4 says each data channel has a priority attribute.  Does this attribut= e apply to reliable messages, or only unreliable?  I can’t find = it documented.  If it does not apply to the CLUE data channel, it woul= d be good to say so.

 

3.3.2 – “A CLUE entity MUST NOT use the = partial reliability and limited retransmission extensions defined in [RFC37= 58].”  Should this be more specific, in just limiting it for the= CLUE data channel, and not limit it for any other WebRTC Data Channels tha= t might be used for other purposes?  Maybe “A CLUE entity MUST N= OT use the partial reliability and limited retransmission extensions define= d in [RFC3758], for the CLUE data channel.”  Or perhaps more sim= ply “A CLUE data channel MUST NOT use the partial reliability and lim= ited retransmission extensions defined in [RFC3758].”

<= p class=3DMsoNormal> 

3.3.3 –= “A CLUE entity MUST use the ordered delivery SCTP service, as descri= bed in section 6.6 of [RFC4960].” Same comment as above, should this = be limited to just the CLUE data channel?

 

Regards,

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023CRPMBOXPRD08p_-- From nobody Tue Feb 10 08:25:34 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C401A1A3D for ; Tue, 10 Feb 2015 08:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-iqim5TajyU for ; Tue, 10 Feb 2015 08:25:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A561A1A38 for ; Tue, 10 Feb 2015 08:25:22 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-50-54da30f01948 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.0C.04484.0F03AD45; Tue, 10 Feb 2015 17:25:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Tue, 10 Feb 2015 17:25:20 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: WGLC comments on clue-datachannel-07 - Mark's comments Thread-Index: AdBEo5B5/RiwabFpR+i6+V35hy9nBgAYjZpQAA52uQAAA6Hcbw== Date: Tue, 10 Feb 2015 16:25:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6C4914@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6BC829@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6C076C@ESESSMB209.ericsson.se>, <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6C4914ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvje4Hg1shBn0rLS32n7rMbLHuyFNm ByaPJUt+Mnm8eKAUwBTFZZOSmpNZllqkb5fAlfHq2Bymgv6kilP//7I3MG4P7WLk4JAQMJG4 skSvi5ETyBSTuHBvPVsXIxeHkMARRomPL1exQzhLGCXe3jvKDtLAJmAh0f1PG6RBRCBUYvXM TSwgtrCAs0RD524WiLiLxLzl1xlBykUEnCTazoWChFkEVCUeLN4IVsIr4Csx98IjVojx1xkl Vk/4C5bgFAiS+LzlDhOIzQh00PdTa8BsZgFxiaYvK1khDhWQWLLnPDOELSrx8vE/VoiafImu q61QCwQlTs58wjKBUXgWkvZZSMpmISmDiBtIfHl/G8rWlli28DUzhK0v0f3+NBOy+AJG9lWM osWpxUm56UZGeqlFmcnFxfl5enmpJZsYgbFzcMtvgx2ML587HmIU4GBU4uE1KLkZIsSaWFZc mXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRhFjd6Ul+qw1Z7mKGktj 4rqO590yWm9lxeNoe6W959o9R07PehHPpN+hUxkn/d9237VJrPvUxUeWfgqfvl2Wfn5MRk04 kodXbafFLUajexPZbykHSgZufrfDI495yv7yv61/njqw+LHF1jU+PNXHYhKu5nTnnof876/B PUcyYk4yV1gkH36nxFKckWioxVxUnAgA4SeeNH4CAAA= Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments 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, 10 Feb 2015 16:25:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6C4914ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Mark, I believe the priority is defined in the partial reliability draft. And, af= air, the usage is implementation specific. Regards, Christer Sent from my Windows Phone ________________________________ From: Duckworth, Mark Sent: =FD10/=FD02/=FD2015 16:46 To: Christer Holmberg; clue@ietf.org= Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments I couldn=92t find any documentation about how this priority attribute is us= ed. If it really is for partial reliability only, then I agree with you th= at the CLUE document doesn=92t need to say anything more. But I can=92t fi= nd this stated anywhere in draft-ietf-rtcweb-data-channel or any other draf= t. Would it be safer to just say it doesn=92t apply in the CLUE data chann= el document? Mark From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 10, 2015 2:52 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments Hi, Regarding the priority attribute, my understanding is that it is only appli= cable to partial reliability (there is no priority flag/parameter in core S= CTP, as far as I know). Assuming my understanding is correct, I don=92t think we need to say anythi= ng, because we already say that partial reliability is not used. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 9. helmikuuta 2015 22:05 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments Hi Mark, Thanks for your comments! I agree with your suggestion to make it clear that the text is talking abou= t the CLUE data channel. Regards, Christer From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02 To: Christer Holmberg; clue@ietf.org Subject: WGLC comments on clue-datachannel-07 The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can=92t find it documented. If it does not apply to the CLUE= data channel, it would be good to say so. 3.3.2 =96 =93A CLUE entity MUST NOT use the partial reliability and limited= retransmission extensions defined in [RFC3758].=94 Should this be more sp= ecific, in just limiting it for the CLUE data channel, and not limit it for= any other WebRTC Data Channels that might be used for other purposes? May= be =93A CLUE entity MUST NOT use the partial reliability and limited retran= smission extensions defined in [RFC3758], for the CLUE data channel.=94 Or= perhaps more simply =93A CLUE data channel MUST NOT use the partial reliab= ility and limited retransmission extensions defined in [RFC3758].=94 3.3.3 =96 =93A CLUE entity MUST use the ordered delivery SCTP service, as d= escribed in section 6.6 of [RFC4960].=94 Same comment as above, should this= be limited to just the CLUE data channel? Regards, Mark --_000_7594FB04B1934943A5C02806D1A2204B1D6C4914ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Mark,

I believe the priority is defined in the partial reliability draft. And, af= air, the usage is implementation specific.

Regards,

Christer

Sent from my Windows Phone
From: Duckworth, Mark
Sent: =FD10= /=FD02/=FD2015 16:46
To: Christer Holmberg; clue@ietf.org
Subject: RE: W= GLC comments on clue-datachannel-07 - Mark's comments

I couldn=92t find any = documentation about how this priority attribute is used.  If it really= is for partial reliability only, then I agree with you that the CLUE docum= ent doesn=92t need to say anything more.  But I can=92t find this stated anywhere in draft-ietf-rtcweb-data-channel or any other draft.  Would it be safe= r to just say it doesn=92t apply in the CLUE data channel document?<= /p>

 

Mark

 

From: Christ= er Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, February 10, 2015 2:52 AM
To: Duckworth, Mark; clue@ietf.org
Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments<= /span>

 

Hi,

 

Regarding the priority= attribute, my understanding is that it is only applicable to partial relia= bility (there is no priority flag/parameter in core SCTP, as far as I know)= .

 

Assuming my understand= ing is correct, I don=92t think we need to say anything, because we already= say that partial reliability is not used.

 

Regards,

 

Christer

 

 

From: clue [= mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 9. helmikuuta 2015 22:05
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's co= mments

 

Hi Mark= ,

 <= /span>

Thanks = for your comments!

 <= /span>

I agree= with your suggestion to make it clear that the text is talking about the C= LUE data channel.

 <= /span>

Regards= ,

 <= /span>

Christe= r

 

From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]
Sent: 09 February 2015 22:02
To: Christer Holmberg; clue@ietf.or= g
Subject: WGLC comments on clue-datachannel-07

 

The document looks good, I have only a couple minor = suggestions.

 

draft-ietf-rtcweb-data-channel section 6.4 says each= data channel has a priority attribute.  Does this attribute apply to = reliable messages, or only unreliable?  I can=92t find it documented.&= nbsp; If it does not apply to the CLUE data channel, it would be good to say so.

 

3.3.2 =96 =93A CLUE entity MUST NOT use the partial = reliability and limited retransmission extensions defined in [RFC3758].=94&= nbsp; Should this be more specific, in just limiting it for the CLUE data c= hannel, and not limit it for any other WebRTC Data Channels that might be used for other purposes?  Maybe =93A CLUE= entity MUST NOT use the partial reliability and limited retransmission ext= ensions defined in [RFC3758], for the CLUE data channel.=94  Or perhap= s more simply =93A CLUE data channel MUST NOT use the partial reliability and limited retransmission extensions defined in [= RFC3758].=94

 

3.3.3 =96 =93A CLUE entity MUST use the ordered deli= very SCTP service, as described in section 6.6 of [RFC4960].=94 Same commen= t as above, should this be limited to just the CLUE data channel?

 

Regards,

Mark

--_000_7594FB04B1934943A5C02806D1A2204B1D6C4914ESESSMB209erics_-- From nobody Tue Feb 10 10:13:10 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BF91A1AFE for ; Tue, 10 Feb 2015 10:13:09 -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 d_5zP1Xa5Le9 for ; Tue, 10 Feb 2015 10:13:06 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.195]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE6A1A1B15 for ; Tue, 10 Feb 2015 10:13:04 -0800 (PST) Received: from [216.82.241.100] by server-3.bemta-8.messagelabs.com id 43/7B-03004-F2A4AD45; Tue, 10 Feb 2015 18:13:03 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-220.messagelabs.com!1423591981!15026247!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14646 invoked from network); 10 Feb 2015 18:13:02 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-13.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 10 Feb 2015 18:13:02 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 10 Feb 2015 10:13:16 -0800 From: "Duckworth, Mark" To: Christer Holmberg , "clue@ietf.org" Date: Tue, 10 Feb 2015 10:12:58 -0800 Thread-Topic: WGLC comments on clue-datachannel-07 - Mark's comments Thread-Index: AdBEo5B5/RiwabFpR+i6+V35hy9nBgAYjZpQAA52uQAAA6HcbwADpUgQ Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C080@CRPMBOXPRD08.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1D6BC829@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6C076C@ESESSMB209.ericsson.se>, <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C023@CRPMBOXPRD08.polycom.com> <7594FB04B1934943A5C02806D1A2204B1D6C4914@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6C4914@ESESSMB209.ericsson.se> 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_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C080CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments 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, 10 Feb 2015 18:13:09 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C080CRPMBOXPRD08p_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Christer, You are correct, thanks for pointing that out. I found the priority attribu= te is defined in draft-ietf-tsvwg-sctp-prpolicies. It is for partial relia= bility usage, so the CLUE data channel document can ignore it. Mark From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 10, 2015 11:25 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments Hi Mark, I believe the priority is defined in the partial reliability draft. And, af= air, the usage is implementation specific. Regards, Christer Sent from my Windows Phone ________________________________ From: Duckworth, Mark Sent: =FD10/=FD02/=FD2015 16:46 To: Christer Holmberg; clue@ietf.org= Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments I couldn=92t find any documentation about how this priority attribute is us= ed. If it really is for partial reliability only, then I agree with you th= at the CLUE document doesn=92t need to say anything more. But I can=92t fi= nd this stated anywhere in draft-ietf-rtcweb-data-channel or any other draf= t. Would it be safer to just say it doesn=92t apply in the CLUE data chann= el document? Mark From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 10, 2015 2:52 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: WGLC comments on clue-datachannel-07 - Mark's comments Hi, Regarding the priority attribute, my understanding is that it is only appli= cable to partial reliability (there is no priority flag/parameter in core S= CTP, as far as I know). Assuming my understanding is correct, I don=92t think we need to say anythi= ng, because we already say that partial reliability is not used. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 9. helmikuuta 2015 22:05 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] WGLC comments on clue-datachannel-07 - Mark's comments Hi Mark, Thanks for your comments! I agree with your suggestion to make it clear that the text is talking abou= t the CLUE data channel. Regards, Christer From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02 To: Christer Holmberg; clue@ietf.org Subject: WGLC comments on clue-datachannel-07 The document looks good, I have only a couple minor suggestions. draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a pri= ority attribute. Does this attribute apply to reliable messages, or only u= nreliable? I can=92t find it documented. If it does not apply to the CLUE= data channel, it would be good to say so. 3.3.2 =96 =93A CLUE entity MUST NOT use the partial reliability and limited= retransmission extensions defined in [RFC3758].=94 Should this be more sp= ecific, in just limiting it for the CLUE data channel, and not limit it for= any other WebRTC Data Channels that might be used for other purposes? May= be =93A CLUE entity MUST NOT use the partial reliability and limited retran= smission extensions defined in [RFC3758], for the CLUE data channel.=94 Or= perhaps more simply =93A CLUE data channel MUST NOT use the partial reliab= ility and limited retransmission extensions defined in [RFC3758].=94 3.3.3 =96 =93A CLUE entity MUST use the ordered delivery SCTP service, as d= escribed in section 6.6 of [RFC4960].=94 Same comment as above, should this= be limited to just the CLUE data channel? Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C080CRPMBOXPRD08p_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi Christer,

You are correct, thanks for pointing that out. I fo= und the priority attribute is defined in draft-ietf-tsvwg-sctp-prpolicies.= =A0 It is for partial reliability usage, so the CLUE data channel document = can ignore it.

Mark

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
= Sent: Tuesday, February 10, 2015 11:25 AM
To: Duckworth, M= ark; clue@ietf.org
Subject: RE: WGLC comments on clue-datachannel= -07 - Mark's comments

 

Hi Mark,

I beli= eve the priority is defined in the partial reliability draft. And, afair, t= he usage is implementation specific.

Regards,

Christer
Sent from my Windows Phone

From: Duckworth, M= ark
To: Christer Holmberg; clue@ietf.org
Subject: RE: WGLC = comments on clue-datachannel-07 - Mark's comments

I couldn=92t fin= d any documentation about how this priority attribute is used.  If it = really is for partial reliability only, then I agree with you that the CLUE= document doesn=92t need to say anything more.  But I can=92t find thi= s stated anywhere in draft-ietf-rtcweb-data-channel or any other draft.&nbs= p; Would it be safer to just say it doesn=92t apply in the CLUE data channe= l document?

 

Mark

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, February 10, 2015 2:52 AM
To: Duckworth, M= ark; clue@ietf.org
Subject: RE: WGLC comments on clue-datachannel= -07 - Mark's comments

 

Hi= ,

&= nbsp;

Regarding the priority attribute, my understanding is that it is only ap= plicable to partial reliability (there is no priority flag/parameter in cor= e SCTP, as far as I know).

 

Assuming my understanding is correct, I don=92t= think we need to say anything, because we already say that partial reliabi= lity is not used.

 

Regards,

 

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

 

 

From: clue [mailto:clue-bounces@ietf.org] On Be= half Of Christer Holmberg
Sent: 9. helmikuuta 2015 22:05
<= b>To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] WGLC= comments on clue-datachannel-07 - Mark's comments

 

Hi Mark,

 

Thanks for your comments!

 

I agree with your s= uggestion to make it clear that the text is talking about the CLUE data cha= nnel.

 

Regards,

 

Christ= er

 

From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] Sent: 09 February 2015 22:02
To: Christer Holmberg; clue@ietf.org
Subject: WGLC comm= ents on clue-datachannel-07

=  

The doc= ument looks good, I have only a couple minor suggestions.

 

draft-ietf-rtcw= eb-data-channel section 6.4 says each data channel has a priority attribute= .  Does this attribute apply to reliable messages, or only unreliable?=   I can=92t find it documented.  If it does not apply to the CLUE= data channel, it would be good to say so.

 

3.3.2 =96 =93A CLUE entity MUS= T NOT use the partial reliability and limited retransmission extensions def= ined in [RFC3758].=94  Should this be more specific, in just limiting = it for the CLUE data channel, and not limit it for any other WebRTC Data Ch= annels that might be used for other purposes?  Maybe =93A CLUE entity = MUST NOT use the partial reliability and limited retransmission extensions = defined in [RFC3758], for the CLUE data channel.=94  Or perhaps more s= imply =93A CLUE data channel MUST NOT use the partial reliability and limit= ed retransmission extensions defined in [RFC3758].=94

 

3.3.3 =96 =93A CLUE= entity MUST use the ordered delivery SCTP service, as described in section= 6.6 of [RFC4960].=94 Same comment as above, should this be limited to just= the CLUE data channel?

 

Regards,

Mark<= o:p>

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C080CRPMBOXPRD08p_-- From nobody Tue Feb 10 14:56:08 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6831A873B for ; Tue, 10 Feb 2015 14:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j99vxSE9ogMD for ; Tue, 10 Feb 2015 14:56:00 -0800 (PST) Received: from alum-mailsec-scanner-1.mit.edu (alum-mailsec-scanner-1.mit.edu [18.7.68.12]) by ietfa.amsl.com (Postfix) with ESMTP id 92EB21A1AC3 for ; Tue, 10 Feb 2015 14:56:00 -0800 (PST) X-AuditID: 1207440c-f79376d00000680a-05-54da8c7f5718 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 47.33.26634.F7C8AD45; Tue, 10 Feb 2015 17:55:59 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t1AMtw3b004512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Feb 2015 17:55:59 -0500 Message-ID: <54DA8C7D.8080303@alum.mit.edu> Date: Tue, 10 Feb 2015 17:55:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixO6iqFvfcyvEYOkuNYv9py4zOzB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+NV5w/2giaeirbXk1gbGC9ydjFyckgImEh0Lu9kgbDFJC7c W88GYgsJXGaU6Jxc1cXIBWT/ZpJ4++0sM0iCV0BbYuLmTUxdjBwcLAKqEleuZYKE2QS0JOYc +s8CEhYVSJa4sSgGolpQ4uTMJ2BhESD75RVBkLCwgIXEt3mHoDYFSjRO3c0OYnMKBEns2LER 7BpmAVuJO3N3M0PY8hLNW2czT2Dkn4Vk6iwkZbOQlC1gZF7FKJeYU5qrm5uYmVOcmqxbnJyY l5dapGuol5tZopeaUrqJERJ4PDsYv62TOcQowMGoxMNbkHgzRIg1say4MvcQoyQHk5Io78+O WyFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHj944FyvCmJlVWpRfkwKWkOFiVxXtUl6n5CAumJ JanZqakFqUUwWRkODiUJ3vxuoEbBotT01Iq0zJwShDQTByfIcC4pkeLUvJTUosTSkox4UCzG FwOjESTFA7S3FaSdt7ggMRcoCtF6ilFRSpw3DSQhAJLIKM2DGwtLJ68YxYG+FOZ9CVLFA0xF cN2vgAYzAQ0uKLgBMrgkESEl1cDIVpi3Uv9o9qoAY+lznh5q12Luv9jy6nwD63HmoIMPOzIU 752enMAZKMSbNHnJPxVPs8dB1e3rvlgEcfvEx3p1VjWeU1Uu9wk9dMXN1DJ1lxung8QvnS+H TYrYjQq8q7a/ZZvQNtXkZGLSryevztSJ3heYtKqfyWjD1Ds5yj8rMiWy2M7KSSmxFGckGmox FxUnAgB3GYEXAgMAAA== Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-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, 10 Feb 2015 22:56:04 -0000 On 2/9/15 3:01 PM, Duckworth, Mark wrote: > The document looks good, I have only a couple minor suggestions. > > draft-ietf-rtcweb-data-channel section 6.4 says each data channel has a > priority attribute. Does this attribute apply to reliable messages, or > only unreliable? I can’t find it documented. If it does not apply to > the CLUE data channel, it would be good to say so. I *think* it does apply to reliable messages. (I'm remembering conversations in meetings, not text.) It would potentially affect the interaction between channels. But since it is only pertinent when multiple channels are in use I think we should say as little as possible about it. > 3.3.2 – “A CLUE entity MUST NOT use the partial reliability and limited > retransmission extensions defined in [RFC3758].” Should this be more > specific, in just limiting it for the CLUE data channel, and not limit > it for any other WebRTC Data Channels that might be used for other > purposes? Maybe “A CLUE entity MUST NOT use the partial reliability and > limited retransmission extensions defined in [RFC3758], for the CLUE > data channel.” Or perhaps more simply “A CLUE data channel MUST NOT use > the partial reliability and limited retransmission extensions defined in > [RFC3758].” Yeah. I commented on this too. > 3.3.3 – “A CLUE entity MUST use the ordered delivery SCTP service, as > described in section 6.6 of [RFC4960].” Same comment as above, should > this be limited to just the CLUE data channel? Agree. From nobody Tue Feb 10 15:05:37 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217261A871D for ; Tue, 10 Feb 2015 15:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcGFtM6Ncili for ; Tue, 10 Feb 2015 15:05:33 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 639EB1A6FFE for ; Tue, 10 Feb 2015 15:05:32 -0800 (PST) X-AuditID: 12074413-f79f26d0000030e7-37-54da8ebb2c0d Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A6.CF.12519.BBE8AD45; Tue, 10 Feb 2015 18:05:31 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t1AN5UoN005025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Feb 2015 18:05:31 -0500 Message-ID: <54DA8EBA.1070308@alum.mit.edu> Date: Tue, 10 Feb 2015 18:05:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixO6iqLu771aIwbIdshb7T11mdmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8ad2/PZCiZoVNzePI21gXGufBcjB4eEgInEydeGXYycQKaY xIV769m6GLk4hAQuM0r0HT0A5fxmkrh6ci8rSBWvgLbEpJ7HjCA2i4CqROvXD2wgNpuAlsSc Q/9ZQIaKCiRL3FgUA1EuKHFy5hOwsAiQ/fKKIEhYWMBbon/vF7CJQgIBEtf+PGMHsTkFAiVO rOwEm8gsYCtxZ+5uZghbXmL72znMExj5ZyGZOgtJ2SwkZQsYmVcxyiXmlObq5iZm5hSnJusW Jyfm5aUW6Zrr5WaW6KWmlG5ihISe8A7GXSflDjEKcDAq8fCeSL4ZIsSaWFZcmXuIUZKDSUmU 92fHrRAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrz+8UA53pTEyqrUonyYlDQHi5I4r9oSdT8h gfTEktTs1NSC1CKYrAwHh5IE7/FeoEbBotT01Iq0zJwShDQTByfIcC4pkeLUvJTUosTSkox4 UDTGFwPjESTFA7T3Dkg7b3FBYi5QFKL1FKOilDjvLpCEAEgiozQPbiwsobxiFAf6Upj3NEgV DzAZwXW/AhrMBDS4oOAGyOCSRISUVAOj2/fna8p/2bdsF1gke5BdqfLhll3uhmyT/qwXkN1a +tjuutox8chtBbErdZRPznnZoviVaZXC9vuztx698PtWyiHFnD2LNNvjf2yMPvFGftVPmzVn PQLjmQ4+MTF/pcYa1XswZOLdGebPVlwUDlgtVKP7w+NnQOvzRsVpzTIGzdxbpZoW8kb3KbEU ZyQaajEXFScCAJWcim4DAwAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 23:05:36 -0000 Here is my WGLC review of draft-ietf-clue-datachannel-07: * Section 2: WebRTC Data Channel refers to a SCTPoDTLS association [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media data between two entities, according to the procedures in [I-D.ietf-rtcweb-data-channel]. IMO the above is wrong! IIUC "WebRTC Data Channel" refers to a single channel, namely a pair of SCTP streams, over an SCTPoDTLS association. [I-D.ietf-rtcweb-data-channel] says: The realization of a data channel is a pair of one incoming stream and one outgoing SCTP stream having the same SCTP stream identifier. How these SCTP stream identifiers are selected is protocol and implementation dependent. This allows a bidirectional communication. So I suggest the following to replace the above: WebRTC Data Channel refers to a pair of SCTP streams over a SCTPoDTLS association that is used to transport non-media data between two entities, as defined in [I-D.ietf-rtcweb-data-channel]. At the end of the section is: [RFC4960] defines an SCTP stream as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. [RFC4960] defines an SCTP identifier as a unsigned integer, which identifies a SCTP stream. I don't understand how to interpret these in context. The section is listing conventions. Does "[RFC4960]" name a convention? How about: SCTP stream is defined in [RFC4960] as a unidirectional logical channel established from one to another associated SCTP endpoint, within which all user messages are delivered in sequence except for those submitted to the unordered delivery service. SCTP identifier is defined in [RFC4960] as a unsigned integer, which identifies a SCTP stream. * Section 3.2.1.2 I think it would be good to mention that each CLUE entity is free to choose the sctp-port value at which it receives messages. CLUE does not prescribe any particular value. * Section 3.2.2 This starts with 'When the SDP-based "SCTP over DTLS" data channel negotiation mechanism is used ...'. This suggests that there may be some other way. How about: The SDP-based "SCTP over DTLS" data channel negotiation mechanism is used to establish a CLUE data channel. The values of the ... I commented on the dcmap parameters in reply to another message. * Section 3.3.1 I find table 3 to be confusing. In spite of the text to the contrary it seems to say that PPID 51 explicitly identifies CLUE. I suggest simply removing Table 3. * Section 3.3.2 I suggest modifying the 2nd paragraph as follows: A CLUE entity MUST NOT use the partial reliability and limited retransmission extensions (defined in [RFC3758], enabled with the dcmap options 'max-retr' and 'max-time') for the CLUE data channel. (Otherwise this might be read to forbid using these for other data channels.) Mark also commented on this. * Section 3.3.3 I suggest revising this to read: A CLUE entity MUST use the ordered delivery SCTP service, as described in section 6.6 of [RFC4960]. This service is enabled either by omitting the 'ordered' option from the dcmap attribute, or by specifying 'ordered="1"' in the dcmap attribute. But this also keys into the other discussion of ordered. So make this conditional on that. * Section 3.3.6 I think this should say *both* streams making up the channel must be reset. When a reset is received on one stream, a reset MUST immediately be sent on the other stream of the channel. (Unless one has already been sent.) * Section 5.2 I agree with others that the dcmap subprotocol value should utilize the same registry as used for DCEP. That's all, Paul On 1/30/15 11:10 AM, Daniel Burnett wrote: > To all CLUE participants, > > Other than dependencies there do not seem to be any major outstanding > issues remaining for the data channel draft, so I am starting a WGLC > today. The end of this WGLC will be end of the day (wherever you are) > on Friday February 13. That gives two full weeks from today. > > If all is in order this will be the last review of this document by the > WG before it goes to the ADs and the IESG. Now is the time for careful, > thorough reviews of the full document. Thankfully, the document is very > short and easy to read since it largely references other documents. > Familiarity with both MMUSIC work and WebRTC data channels is a plus but > not required. > > To help in planning, please respond to this message if you plan to > submit a review. We can only move forward if we get reviews! > > And yes, I will be a doing a WGLC review of the draft myself :) > > -- dan > (for all the chairs) > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Feb 10 15:06:44 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C1A1A874D for ; Tue, 10 Feb 2015 15:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN-o2qChE61i for ; Tue, 10 Feb 2015 15:06:40 -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 6792C1A6FFE for ; Tue, 10 Feb 2015 15:06:40 -0800 (PST) X-AuditID: 12074414-f797f6d000004084-82-54da8eff2c1b 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 63.FA.16516.FFE8AD45; Tue, 10 Feb 2015 18:06:39 -0500 (EST) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t1AN6d6n005062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Feb 2015 18:06:39 -0500 Message-ID: <54DA8EFF.8090302@alum.mit.edu> Date: Tue, 10 Feb 2015 18:06:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqPu/71aIQc98I4v9py4zOzB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+PqqZ+MBY+FKyacbmdqYPzA38XIySEhYCJx+9ITZghbTOLC vfVsXYxcHEIClxkltj76xgLh/GaS2DZzMxtIFa+AtsTCa51MXYwcHCwCqhL/fqiBhNkEtCTm HPrPAhIWFUiWuLEoBqJaUOLkzCdgYREg++UVQZCwsECKxLKzB5ghpvczSnS3b2MHSXAK+Eks ejGFFcRmFrCVuDN3NzOELS+x/e0c5gmM/LOQjJ2FpGwWkrIFjMyrGOUSc0pzdXMTM3OKU5N1 i5MT8/JSi3Qt9HIzS/RSU0o3MUKCT2QH45GTcocYBTgYlXh4CxJvhgixJpYVV+YeYpTkYFIS 5f3ZcStEiC8pP6UyI7E4I76oNCe1+BCjBAezkgivfzxQjjclsbIqtSgfJiXNwaIkzvttsbqf kEB6YklqdmpqQWoRTFaGg0NJgtcRGGVCgkWp6akVaZk5JQhpJg5OkOFcUiLFqXkpqUWJpSUZ 8aB4jC8GRiRIigdobyhIO29xQWIuUBSi9RSjopQ4rzNIQgAkkVGaBzcWllJeMYoDfSnMO7UX qIoHmI7gul8BDWYCGlxQcANkcEkiQkqqgVEp6YTYwgf/z3qmbGO7nnzk+5ffxous7q5TCfg3 2fowz7w4By/e/SwTTH6fzbrKO6fwf/TahZFSJz8cuvihQMdq7ofJB4wW2v+KD/FVZEx+Umu+ dMH9vBDrBPeNT4Obmh/bza87VGTWIG0eYGel8ixV5Fav5w6mJeyZL0MKSu6zfozJNVy485gS S3FGoqEWc1FxIgAgSv5BBAMAAA== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments 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, 10 Feb 2015 23:06:43 -0000 On 2/8/15 9:18 AM, Christer Holmberg wrote: > > Hi, > >>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will be >>> more common than TCP do we want to make a recommendation on >>> what transport CLUE endpoint should support in order to maximise interop? >> >> I guess we could say that TCP SHOULD only be used if needed for ICE purpose. >> >> But, I'd like to make sure other are ok with such approach too. > > What about adding the following text: > > "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association used to realize > the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless > the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used and > the ICE procedures determines that TCP transport is required." WFM > ----------- > >>> 4. Section 3.2.2: Perhaps we should explicitly mention the data channel type used from [I-D.ietf-rtcweb-data-protocol] e.g. >>> DATA_CHANNEL_RELIABLE. >>> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in >>> Table 2 that the ordered, max-retr and max-time are not used due to the use of a reliable channel. >> >> I support that. > > What about adding the following text: > > "NOTE: As CLUE entities are required to use ordered SCTP message delivery, > with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg] > the ordered, max-retr and max-time attribute parameters are not used when > negotiating CLUE data channels." This is good, except that we should not exclude the possibility of explicitly specifying reliable ordered delivery, by including 'ordered' with the appropriate value. (I can't tell whether that is "0" or "1". Right how the text defines them both as meaning ordered.) > ----------- > >>> 7. Section 5.1/5.2: The registries that need to be used for DCMAP and >>> the WebRTC sub-protocol registry need to be sorted out. I'm not sure >>> why two registries would be needed for essentially the same thing. >> >> I agree. I suggest to send an e-mail to the MMUSIC list regarding that, and suggest that the same registry is used. > > I sent an e-mail regarding this to the MMUSIC list. Clearly this needs to be defined there. But I agree that there should not be separate registries. Thanks, Paul > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Feb 10 23:04:31 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AAC1A802E for ; Tue, 10 Feb 2015 23:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEDnt_EuDvr5 for ; Tue, 10 Feb 2015 23:04:27 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D251A7D81 for ; Tue, 10 Feb 2015 23:04:26 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-d1-54dafef848ca Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0A.13.04076.8FEFAD45; Wed, 11 Feb 2015 08:04:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 08:04:24 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC comments on clue-datachannel-07 Thread-Index: AdBEoxq66BQiebcUQ82B9xGhBaL+6AA2T6OAABMZhfA= Date: Wed, 11 Feb 2015 07:04:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CA6FE@ESESSMB209.ericsson.se> References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4BFB5@CRPMBOXPRD08.polycom.com> <54DA8C7D.8080303@alum.mit.edu> In-Reply-To: <54DA8C7D.8080303@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje6Pf7dCDDadtrDYf+oys8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mvwf/sxf0slc8nfeHuYHxMmsXIyeHhICJ xIe319ggbDGJC/fWA9lcHEICRxgl9s1axQThLGGU2Pj6MXMXIwcHm4CFRPc/bZAGEQFPiR0f pzCD2MJA4aXPTrNAxC0lpuxuY4OwrSTOnnrLBGKzCKhK3F23hx3E5hXwlbi7ciqYLSRQLHGv YSk7yHhOAR2Jrt9eIGFGoHu+n1oD1sosIC5x68l8Jog7BSSW7DnPDGGLSrx8/A/qFyWJHxsu sUDU60gs2P2JDcLWlli28DUzxFpBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcXFu upGRXmpRZnJxcX6eXl5qySZGYJQc3PLbagfjweeOhxgFOBiVeHg3HL0VIsSaWFZcmXuIUZqD RUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRgW76I+fjvA8Z5weJfRQyzc/7r15 Eu9qj/l1J/Y8S9UoOh5wXEFzRdAOw8sx8/ct3cOXdv1DIL+lRvbWZcY6Adtuh4ZtO16fd/TL 133bHxpdmrS+pzzXO1hEft4LjSnZZTFXm9XVIrhXG6d/ilh2Zuq78+td995PWbl2+RYv0S8T XqfHK705EaHEUpyRaKjFXFScCAB5I1y8cwIAAA== Archived-At: Subject: Re: [clue] WGLC comments on clue-datachannel-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, 11 Feb 2015 07:04:29 -0000 Hi, >> The document looks good, I have only a couple minor suggestions. >> >> draft-ietf-rtcweb-data-channel section 6.4 says each data channel has=20 >> a priority attribute. Does this attribute apply to reliable messages,=20 >> or only unreliable? I can't find it documented. If it does not apply=20 >> to the CLUE data channel, it would be good to say so. > > I *think* it does apply to reliable messages. (I'm remembering conversati= ons in meetings, not text.) It=20 > would potentially affect the interaction between channels. But since it i= s only pertinent when multiple=20 > channels are in use I think we should say as little as possible about it. Even if we wanted to say something, I am not sure exactly what we could say= . If a CLUE entity also implements a data channel for X, it is really an impl= ementation issue how priority is organized. Regards, Christer From nobody Wed Feb 11 00:07:02 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712EB1A86FC for ; Wed, 11 Feb 2015 00:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXX7RKw-4DhO for ; Wed, 11 Feb 2015 00:06:57 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424901A802D for ; Wed, 11 Feb 2015 00:06:57 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-f4-54db0d9f524f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.07.24955.F9D0BD45; Wed, 11 Feb 2015 09:06:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 09:06:55 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAHUKDIAAEslKEA== Date: Wed, 11 Feb 2015 08:06:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CAADC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54DA8EFF.8090302@alum.mit.edu> In-Reply-To: <54DA8EFF.8090302@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje583tshBt+6FS32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjYsc09oL1HBVN9/+wNzDeY+ti5OSQEDCR 2HvxGSOELSZx4d56sLiQwBFGieapmV2MXED2EkaJayemAyU4ONgELCS6/2mD1IgIeErs+DiF GcQWFkiR+P93NytEPFVi6dPTTBC2k8SmO71gNouAqsTuWS3sIDavgK/ExYV7WSDmb2aUWN10 BizBKaAjserAbbChjEAHfT+1BqyZWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4StJPFjwyUW iHodiQW7P7FB2NoSyxa+ZoZYLChxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYhQtTi1Oyk03 MtZLLcpMLi7Oz9PLSy3ZxAiMk4NbfqvuYLz8xvEQowAHoxIP74ajt0KEWBPLiitzDzFKc7Ao ifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY8yDMfV2cm/aBPfVGrftkd2vf4lo+ xz4u2Xy1xNEPEvPebGdg55vMc5jVxtw8jykyXHzD3G/BHapzfit0Ok08ejgy74usZldc1+7l z4w4p8Yd8domun753SWyny9rx911ej1HrOJ9Kd/3043/D/4PLJLzmFW78dIX5gjBQtH6qPSz P/f+5mpTYinOSDTUYi4qTgQA685tb3QCAAA= Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments 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, 11 Feb 2015 08:06:59 -0000 Hi, ... >>>> 4. Section 3.2.2: Perhaps we should explicitly mention the data channe= l type used from [I-D.ietf-rtcweb-data-protocol] e.g. >>>> DATA_CHANNEL_RELIABLE. >>>> If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate=20 >>>> in Table 2 that the ordered, max-retr and max-time are not used due to= the use of a reliable channel. >>> >>> I support that. >> >> What about adding the following text: >> >> "NOTE: As CLUE entities are required to use ordered SCTP message delive= ry, >> with full reliability, according to the procedures in [I-D.ietf-mmusic-= data-channel-sdpneg] >> the ordered, max-retr and max-time attribute parameters are not used = when >> negotiating CLUE data channels." > > This is good, except that we should not exclude the possibility of explic= itly specifying reliable ordered delivery, by including 'ordered'=20 > with the appropriate value. (I can't tell whether that is "0" or "1".=20 > Right how the text defines them both as meaning ordered.) Correct. Regards, Christer From nobody Wed Feb 11 00:48:40 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475C21A03A1 for ; Wed, 11 Feb 2015 00:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymW51pes0orS for ; Wed, 11 Feb 2015 00:48:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267791A0382 for ; Wed, 11 Feb 2015 00:48:32 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-fb-54db175e2076 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 93.2F.04484.E571BD45; Wed, 11 Feb 2015 09:48:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 09:48:30 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments Thread-Index: AdBF0hTQx0zvLBvrRLyWjvRWrr2JXw== Date: Wed, 11 Feb 2015 08:48:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvjW68+O0Qg3+7mCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjZsMKtoLPehUzXt1hbmB8rtLFyMkhIWAi cWHFaXYIW0ziwr31bF2MXBxCAkcYJWb8O80M4SxhlDj4/T1jFyMHB5uAhUT3P22QBhEBT4kd H6cwg9jCAvES+9umMIGUiAgkSHStSYco0ZNYMPEfC4jNIqAq8XTrJLBdvAK+El82HASzGYH2 fj+1hgnEZhYQl7j1ZD4TxD0CEkv2nGeGsEUlXj7+xwphK0n82HCJBaJeR2LB7k9sELa2xLKF r5kh5gtKnJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJL NjECg/7glt8GOxhfPnc8xCjAwajEw7vh6K0QIdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwpnyad2FPjOr7/45Rkoq9u1+J9Jh0m56PdWMPtAl8frrnmLrK HVX9rvt5KRqmERuCJj3nv7tg5Yd0EfuFgR82yy3buiJ1n/jWK8+OOd0LSHN8cDbylPP7DTdD Oj/wiemqR1i26t155XVVR8F0QnXw4XSe86+7+jiOBe5787C7WNjl6Pxb96wrlFiKMxINtZiL ihMBBSUxClsCAAA= Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments 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, 11 Feb 2015 08:48:36 -0000 Hi Paul, Thanks for your comments! Reply inline. > * Section 2: > > WebRTC Data Channel refers to a SCTPoDTLS association > [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media > data between two entities, according to the procedures in > [I-D.ietf-rtcweb-data-channel]. > > IMO the above is wrong! IIUC "WebRTC Data Channel" refers to a single cha= nnel, namely a pair of SCTP streams, over an SCTPoDTLS association.=20 > [I-D.ietf-rtcweb-data-channel] says: > > The realization of a data channel is a pair of one incoming stream > and one outgoing SCTP stream having the same SCTP stream identifier. > How these SCTP stream identifiers are selected is protocol and > implementation dependent. This allows a bidirectional communication. > > So I suggest the following to replace the above: > > WebRTC Data Channel refers to a pair of SCTP streams over a > SCTPoDTLS association that is used to transport non-media > data between two entities, as defined in > [I-D.ietf-rtcweb-data-channel]. I'll fix as suggested. > At the end of the section is: > > [RFC4960] defines an SCTP stream as a unidirectional logical channel > established from one to another associated SCTP endpoint, within > which all user messages are delivered in sequence except for those > submitted to the unordered delivery service. > > [RFC4960] defines an SCTP identifier as a unsigned integer, which > identifies a SCTP stream. > > I don't understand how to interpret these in context. The section is list= ing conventions. Does "[RFC4960]" name a convention? How about: > > SCTP stream is defined in [RFC4960] as a unidirectional logical > channel established from one to another associated SCTP endpoint, > within which all user messages are delivered in sequence except for > those submitted to the unordered delivery service. > > SCTP identifier is defined in [RFC4960] as a unsigned integer, which > identifies a SCTP stream. I'll fix as suggested. ------------------------- > * Section 3.2.1.2 > > I think it would be good to mention that each CLUE entity is free to choo= se the sctp-port value at which it receives messages. CLUE does not prescri= be any particular value. I suggest the following modified paragraph text: "As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute value is set to the SCTP port of the SCTPoDTLS association. A CLUE enti= ty can choose any valid SCTP port value." ------------------------- > * Section 3.2.2 > > This starts with 'When the SDP-based "SCTP over DTLS" data channel negoti= ation mechanism is used ...'. This suggests that there may be some other wa= y. How about: > > The SDP-based "SCTP over DTLS" data channel negotiation > mechanism is used to establish a CLUE data channel. > The values of the ... I'll fix as suggested. ------------------------- > * Section 3.3.1 > > I find table 3 to be confusing. In spite of the text to the contrary it s= eems to say that PPID 51 explicitly identifies CLUE. I suggest simply remov= ing Table 3. I can do that. I agree it's not really needed anymore. ------------------------- > * Section 3.3.2 > > I suggest modifying the 2nd paragraph as follows: > > A CLUE entity MUST NOT use the partial reliability and limited > retransmission extensions (defined in [RFC3758], enabled with > the dcmap options 'max-retr' and 'max-time') for the CLUE > data channel. > > (Otherwise this might be read to forbid using these for other data > channels.) Mark also commented on this. Mark suggested the following text: "A CLUE data channel MUST NOT use the partial reliability and limited retr= ansmission=20 SCTP extensions defined in [RFC3758]." Personally I would suggest to use Mark's text, and not talk about the dcmap= options in this section, which is about SCTP features and extensions. ------------------------- > * Section 3.3.3 > > I suggest revising this to read: > > A CLUE entity MUST use the ordered delivery SCTP service, as > described in section 6.6 of [RFC4960]. This service is enabled > either by omitting the 'ordered' option from the dcmap attribute, or > by specifying 'ordered=3D"1"' in the dcmap attribute. > > But this also keys into the other discussion of ordered. So make this con= ditional on that. Again, it'd like to keep the dcmap attribute details out of section 3.3, an= d make sure section 3.2 is clear enough. I have been thinking, though, whether it would be a good idea to switch the= order of sections 3.2 and 3.3, in order to first talk about the SCTP exten= sions etc, and then talk about how to signal them. ------------------------- > * Section 3.3.6 > > I think this should say *both* streams making up the channel must be rese= t. When a reset is received on one stream, a reset MUST immediately be sent= on the other stream of the channel. (Unless one has already been > sent.) Christian also had a comment (editorial) on this section. I suggest to modify the paragraph as following: "As described in [I-D.ietf-rtcweb-data-protocol], in order to close a data= channel, an entity sends an SCTP reset=20 message [RFC6525] is sent on its outgoing SCTP stream associated with the = data channel. When the remote peer receives the reset message, it also sends (unless already sent) a res= et message on its outgoing SCTP=20 stream associated with the data channel. The SCTPoDTLS association, and ot= her data channels established on=20 the same association, are not affected by the SCTP reset messages." ------------------------- > * Section 5.2 > > I agree with others that the dcmap subprotocol value should utilize the s= ame registry as used for DCEP. Please provide your comments on the associated MMUSIC list thread :) Regards, Christer From nobody Wed Feb 11 06:41:09 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91B61A88ED for ; Wed, 11 Feb 2015 06:41:06 -0800 (PST) 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 LUtAB5CuxQGG for ; Wed, 11 Feb 2015 06:41:03 -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 8D12C1A88D0 for ; Wed, 11 Feb 2015 06:41:03 -0800 (PST) X-ASG-Debug-ID: 1423665659-05f27518c91da1f30001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id sPGewQEC12M1oUBQ (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 15:40:59 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.169] ([143.225.28.169]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t1BEewXO005636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 15:40:59 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_7CA19A64-1E86-4540-9486-32F0E3235FAB" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Updated CLUE protocol draft In-Reply-To: <54D412F3.4080900@nteczone.com> Date: Wed, 11 Feb 2015 15:40:57 +0100 Message-Id: References: <54D412F3.4080900@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1993) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1423665659 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.15143 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: CLUE Subject: Re: [clue] Updated CLUE protocol draft 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, 11 Feb 2015 14:41:07 -0000 --Apple-Mail=_7CA19A64-1E86-4540-9486-32F0E3235FAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Christian, we actually had a long discussion on this point in Honolulu: = http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF91_C= LUE&chapter=3Dchapter_0 = Time marks for the above recording: - 01:02:31 --> diffs discussion starts - 01:11:06 --> discussion seems to stop... - 01:12:55 --> The tough question arrives: rather than deciding whether = or not to make the diffs mechanism optional, we hum on whether or not to = "define" the diffs mechanism - 01:13:50 --> in the absence of clear consensus on one of the options, = the chairs decide to send this to mailing list - 01:15.13 --> we change topic Once done with the f2f meeting, we've had your e-mail on the mailing = list about this subject (on the 28th of November), to which just Paul = answered on December 1st. So, no decision was taken on the ML. My personal feeling is that there's not enough energy/interest around = CLUE to justify keeping on discussing. Together with Roberta, we tried = to make an effort and put the documents we're responsible for (protocol = and data model) into a consistent (hopefully FINAL) state, in order to = allow the group as a whole to make progress on their final revisions and = bring them (as well as the companion drafts associated with framework, = signaling and data channel) to successful completion. My expectation is = that we're gonna close the WG anyhow sooner or later (rather sooner than = later, indeed). And I personally agree with this plan, given the overall = state of CLUE activities. You will certainly have noticed, e.g., that I = have stopped boring you all with my thoughts on why we keep on strictly = coupling CLUE with SIP! All that said, the diffs mechanism is ready to be re-introduced in our = documents, if the WG sees it fit. My 2 cents, Simon > On 06/feb/2015, at 02:03, Christian Groves = wrote: >=20 > Hello Simon, >=20 > I noticed the diff mechanism was removed. I didn't see anywhere that = it was agreed to do this? If it was I didn't see how to handle the = partial update mechanism moving forward. >=20 > Regards, Christian >=20 > On 6/02/2015 10:39 AM, Simon Pietro Romano wrote: >> Dear all, >>=20 >> we have just uploaded version -03 of the protocol draft. We believe = we have addressed most of the issues that were raised at last IETF in = Honolulu. The document should now be perfectly aligned with the = companion drafts produced by the WG (with special regard to the = signaling document). >>=20 >> Cheers, >>=20 >> Simon >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it = > >>=20 >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=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=_7CA19A64-1E86-4540-9486-32F0E3235FAB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Christian,

we actually had a long discussion on this point in = Honolulu:

http://recordings.conf.meetecho.com/Playout/watch.jsp?recording= =3DIETF91_CLUE&chapter=3Dchapter_0

Time marks for the above = recording:

- = 01:02:31 --> diffs discussion starts
- 01:11:06 = --> discussion seems to stop...
- 01:12:55 = --> The tough question arrives: rather than deciding whether or not = to make the diffs mechanism optional, we hum on whether or not to = "define" the diffs mechanism
- 01:13:50 --> in = the absence of clear consensus on one of the options, the chairs decide = to send this to mailing list
- 01:15.13 --> we = change topic

Once done with the f2f meeting, we've had your e-mail on the = mailing list about this subject (on the 28th of November), to which just = Paul answered on December 1st. So, no decision was taken on the = ML.

My = personal feeling is that there's not enough energy/interest around CLUE = to justify keeping on discussing. Together with Roberta, we tried to = make an effort and put the documents we're responsible for (protocol and = data model) into a consistent (hopefully FINAL) state, in order to allow = the group as a whole to make progress on their final revisions and bring = them (as well as the companion drafts associated with framework, = signaling and data channel) to successful completion. My expectation is = that we're gonna close the WG anyhow sooner or later (rather sooner than = later, indeed). And I personally agree with this plan, given the overall = state of CLUE activities. You will certainly have noticed, e.g., that I = have stopped boring you all with my thoughts on why we keep on strictly = coupling CLUE with SIP!

All that said, the diffs mechanism is ready to be = re-introduced in our documents, if the WG sees it fit.

My 2 cents,

Simon




On = 06/feb/2015, at 02:03, Christian Groves <Christian.Groves@nteczone.com> wrote:

Hello Simon,

I noticed the diff mechanism was removed. I = didn't see anywhere that it was agreed to do this? If it was I didn't = see how to handle the partial update mechanism moving forward.

Regards, Christian

On 6/02/2015 10:39 AM, Simon Pietro Romano = wrote:
Dear all,

we have just = uploaded version -03 of the protocol draft. We believe we have addressed = most of the issues that were raised at last IETF in Honolulu. The = document should now be perfectly aligned with the companion drafts = produced by the WG (with special regard to the signaling document).

Cheers,

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

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







_______________________________________________
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

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






= --Apple-Mail=_7CA19A64-1E86-4540-9486-32F0E3235FAB-- From nobody Wed Feb 11 07:01:13 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E79A1A0368 for ; Wed, 11 Feb 2015 07:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBO8GdN0y3Cn for ; Wed, 11 Feb 2015 07:01:08 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17A01A026A for ; Wed, 11 Feb 2015 07:01:06 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-03v.sys.comcast.net with comcast id r30v1p0032XD5SV01316z8; Wed, 11 Feb 2015 15:01:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-20v.sys.comcast.net with comcast id r3151p00M3Ge9ey013153S; Wed, 11 Feb 2015 15:01:06 +0000 Message-ID: <54DB6EB1.7040006@alum.mit.edu> Date: Wed, 11 Feb 2015 10:01:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> 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=1423666866; bh=RE2ozwYJ+bRooZXi6ztORFGgql3pzdNQP2Fsq3BVzGg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nTCzQr3nlZTIq90JfzmyHUT4L+s7NFyKjdtaaFF27hZ1lyS+J0HINaiiMQ+0IvRKm 23Wco6TWUOradJ9emXUMnX8IKN8VqisALgF8RF/soABwE3GUJx/spQYilAfVf09Gde 7w8+gsMg38ydyHtjaKtPBn8puolwxSlZo2yE1gs6hg8OIT210e3pskqMYVGKTnUsAS m7tHvx2FY9rWy4NhbhlRI1lNNFuPqwI+olFsRLN4uPQ3wubs75HbqGA6Bq680BYEmN HUKzDfxgpx/dfsRGceUG1thbf4jXqODR3cVB+ckY23S/YmoFb4Dj5lM7iLq9wOV3f4 4h8OZpQCAwR1w== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments 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, 11 Feb 2015 15:01:11 -0000 On 2/11/15 3:48 AM, Christer Holmberg wrote: Trimming out settled items: > ------------------------- > >> * Section 3.2.1.2 >> >> I think it would be good to mention that each CLUE entity is free to choose the sctp-port value at which it receives messages. CLUE does not prescribe any particular value. > > I suggest the following modified paragraph text: > > "As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute > value is set to the SCTP port of the SCTPoDTLS association. A CLUE entity > can choose any valid SCTP port value." WFM > ------------------------- > >> * Section 3.3.2 >> >> I suggest modifying the 2nd paragraph as follows: >> >> A CLUE entity MUST NOT use the partial reliability and limited >> retransmission extensions (defined in [RFC3758], enabled with >> the dcmap options 'max-retr' and 'max-time') for the CLUE >> data channel. >> >> (Otherwise this might be read to forbid using these for other data >> channels.) Mark also commented on this. > > Mark suggested the following text: > > "A CLUE data channel MUST NOT use the partial reliability and limited retransmission > SCTP extensions defined in [RFC3758]." > > Personally I would suggest to use Mark's text, and not talk about the dcmap options in this section, which is about SCTP features and extensions. This may require some further discussion. In draft-ietf-rtcweb-data-channel there is a presumption that there is an API used for accessing data channels. The API makes the options appear to the user as being per-channel, even though in the SCTP protocol they are per-message. Similarly the ejzak draft negotiates them on a per-channel basis, and assumes that they will be used that way. I don't know if we are assuming that clue implementations will be using an API that preserves this per-channel behavior, or if we are assuming that the clue implementer will need to take the negotiated values and apply them on a per-message basis. The bottom line is that we prescribe which options must be negotiated for the clue channel, and then we require that the streams be used in a way that is consistent with those options. > ------------------------- > >> * Section 3.3.3 >> >> I suggest revising this to read: >> >> A CLUE entity MUST use the ordered delivery SCTP service, as >> described in section 6.6 of [RFC4960]. This service is enabled >> either by omitting the 'ordered' option from the dcmap attribute, or >> by specifying 'ordered="1"' in the dcmap attribute. >> >> But this also keys into the other discussion of ordered. So make this conditional on that. > > Again, it'd like to keep the dcmap attribute details out of section 3.3, and make sure section 3.2 is clear enough. > > I have been thinking, though, whether it would be a good idea to switch the order of sections 3.2 and 3.3, in order to first talk about the SCTP extensions etc, and then talk about how to signal them. Of course my comment above applies here too. > ------------------------- > >> * Section 3.3.6 >> >> I think this should say *both* streams making up the channel must be reset. When a reset is received on one stream, a reset MUST immediately be sent on the other stream of the channel. (Unless one has already been >> sent.) > > Christian also had a comment (editorial) on this section. > > I suggest to modify the paragraph as following: > > "As described in [I-D.ietf-rtcweb-data-protocol], in order to close a data channel, an entity sends an SCTP reset > message [RFC6525] is sent on its outgoing SCTP stream associated with the data channel. When the remote > peer receives the reset message, it also sends (unless already sent) a reset message on its outgoing SCTP > stream associated with the data channel. The SCTPoDTLS association, and other data channels established on > the same association, are not affected by the SCTP reset messages." Intent above seems fine. But the language isn't quite right: "an entity sends ... is sent" is broken. I think you can simply delete "is sent". > ------------------------- > >> * Section 5.2 >> >> I agree with others that the dcmap subprotocol value should utilize the same registry as used for DCEP. > > Please provide your comments on the associated MMUSIC list thread :) I think I did. Thanks, Paul From nobody Wed Feb 11 11:27:01 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1806D1A8A97 for ; Wed, 11 Feb 2015 11:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvAQvytgxGvE for ; Wed, 11 Feb 2015 11:26:55 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960B61A88FD for ; Wed, 11 Feb 2015 11:26:37 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-41-54dbaceb9123 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.C6.04231.BECABD45; Wed, 11 Feb 2015 20:26:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 20:26:34 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments Thread-Index: AdBF0hTQx0zvLBvrRLyWjvRWrr2JXwAMRhWAAArjG5A= Date: Wed, 11 Feb 2015 19:26:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CD620@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> <54DB6EB1.7040006@alum.mit.edu> In-Reply-To: <54DB6EB1.7040006@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.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje7rNbdDDE5NE7PYf+oys8WKDQdY HZg8/r7/wOSxZMlPpgCmKC6blNSczLLUIn27BK6Mqb/PsRdM1qlY/vM4cwPjO6UuRk4OCQET icWTO5ghbDGJC/fWs3UxcnEICRxhlPh14gwzhLOEUeLWmh72LkYODjYBC4nuf9ogDSICnhI7 Pk4BaxYWiJfY3zaFCaRERCBBomtNOkSJlcTqeZ/BwiwCqhIvTwaAhHkFfCXWT3nIAmILCeRL LHi/iA3E5hTQkfg9YSEriM0IdM73U2uYQGxmAXGJW0/mM0GcKSCxZM95qJNFJV4+/scKYStJ rNh+iRGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAmPk4JbfujsYV792PMQowMGoxMO74eitECHWxLLiytxD jNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MMb+6JI4+FHc6fpMp9tTl8R/ jtE/++z0jb4ZsYLHP9zWvvvgs8z0pI85zaIiU7cds3a1mWy9OaXB+/jyvD9F4paKN4ouv8+4 tfj21BcKE+uTl9z49XX2IyW+KqMVFSfkHih7P1AoLopytjmtejKnalbmpYln74l+Wn+0R/DV dsbJ4SIOFWfSlkcosRRnJBpqMRcVJwIAmwsfK3ICAAA= Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments 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, 11 Feb 2015 19:26:58 -0000 Hi, ------------------------- * Section 3.2.1.2 >>> I think it would be good to mention that each CLUE entity is=20 >>> free to choose the sctp-port value at which it receives messages. CLUE = does not prescribe any particular value. >> >> I suggest the following modified paragraph text: >> >> "As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribu= te >> value is set to the SCTP port of the SCTPoDTLS association. A CLUE = entity >> can choose any valid SCTP port value." > > WFM I'll modify as suggested. ------------------------ * Section 3.3.2 >>> I suggest modifying the 2nd paragraph as follows: >>> >>> A CLUE entity MUST NOT use the partial reliability and limited >>> retransmission extensions (defined in [RFC3758], enabled with >>> the dcmap options 'max-retr' and 'max-time') for the CLUE >>> data channel. >>> >>> (Otherwise this might be read to forbid using these for other data >>> channels.) Mark also commented on this. >> >> Mark suggested the following text: >> >> "A CLUE data channel MUST NOT use the partial reliability and limited r= etransmission >> SCTP extensions defined in [RFC3758]." >> >> Personally I would suggest to use Mark's text, and not talk about the dc= map options=20 >> in this section, which is about SCTP features and extensions. > > This may require some further discussion. > > In draft-ietf-rtcweb-data-channel there is a presumption that there is an= API used=20 > for accessing data channels. The API makes the options appear to the user= as being=20 > per-channel, even though in the SCTP protocol they are per-message. > > Similarly the ejzak draft negotiates them on a per-channel basis, and ass= umes that they will be used that way. > > I don't know if we are assuming that clue implementations will be using a= n API that preserves this=20 > per-channel behavior, or if we are assuming that the clue implementer wil= l need to take the negotiated=20 > values and apply them on a per-message basis. I think we should not make assumptions what API is used.=20 (Unfortunately, draft-data-channel seems to be focused mostly about browser= s and WebRTC.) > The bottom line is that we prescribe which options must be negotiated for= the clue channel, and then > we require that the streams be used in a way that is consistent with thos= e options. We could, odd a note, and inform people that according to [ref-to-data-chan= nel] the SCTP options are applied per channel, i.e. to each message sent on= a channel. ------------------------- * Section 3.3.3 >>> I suggest revising this to read: >>> >>> A CLUE entity MUST use the ordered delivery SCTP service, as >>> described in section 6.6 of [RFC4960]. This service is enabled >>> either by omitting the 'ordered' option from the dcmap attribute, o= r >>> by specifying 'ordered=3D"1"' in the dcmap attribute. >>> >>> But this also keys into the other discussion of ordered. So make this c= onditional on that. >> >> Again, it'd like to keep the dcmap attribute details out of section 3.3,= and make sure section 3.2 is clear enough. >> >> I have been thinking, though, whether it would be a good idea to switch = the order of=20 >> sections 3.2 and 3.3, in order to first talk about the SCTP extensions e= tc, and then talk about how to signal them. > > Of course my comment above applies here too. Correct. However, it seems like your comment is not related to my suggestion of not = talking about dcmap in section 3.3 :) Do you have an opinion on switching sections 3.2 and 3.3?=20 ------------------------- * Section 3.3.6 >>> I think this should say *both* streams making up the channel must be=20 >>> reset. When a reset is received on one stream, a reset MUST=20 >>> immediately be sent on the other stream of the channel. (Unless one=20 >>> has already been sent.) >> >> Christian also had a comment (editorial) on this section. >> >> I suggest to modify the paragraph as following: >> >> "As described in [I-D.ietf-rtcweb-data-protocol], in order to close a d= ata channel, an entity sends an SCTP reset >> message [RFC6525] is sent on its outgoing SCTP stream associated with t= he data channel. When the remote >> peer receives the reset message, it also sends (unless already sent) a = reset message on its outgoing SCTP >> stream associated with the data channel. The SCTPoDTLS association, and= other data channels established on >> the same association, are not affected by the SCTP reset messages." > > Intent above seems fine. But the language isn't quite right: "an entity s= ends ... is sent" is broken. I think=20 > you can simply delete "is sent". "As described in [I-D.ietf-rtcweb-data-protocol], in order to close a dat= a channel, an entity sends an SCTP reset message [RFC6525] on its outgoing SCTP stream associated with the data ch= annel. When the remote peer receives the reset message, it also sends (unless already sent) a re= set message on its outgoing SCTP stream associated with the data channel. The SCTPoDTLS association, and o= ther data channels established on the same association, are not affected by the SCTP reset messages." ------------------------- * Section 5.2 >>> I agree with others that the dcmap subprotocol value should utilize the= same registry as used for DCEP. >> >> Please provide your comments on the associated MMUSIC list thread :) > > I think I did. I know. It was a meant to the whole community :) Regards, Christer From nobody Wed Feb 11 13:41:29 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5461A6EE0 for ; Wed, 11 Feb 2015 13:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCseX1wNF5Fe for ; Wed, 11 Feb 2015 13:41:24 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83F21A6FEC for ; Wed, 11 Feb 2015 13:41:21 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-06v.sys.comcast.net with comcast id r9gc1p0042Fh1PH019hLjn; Wed, 11 Feb 2015 21:41:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-08v.sys.comcast.net with comcast id r9hL1p00J3Ge9ey019hLGv; Wed, 11 Feb 2015 21:41:20 +0000 Message-ID: <54DBCC7E.3090804@alum.mit.edu> Date: Wed, 11 Feb 2015 16:41:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> <54DB6EB1.7040006@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CD620@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CD620@ESESSMB209.ericsson.se> 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=1423690880; bh=vtDbWysmUrf/Xr0He7RXyXCAslnmeonl97z2BvJPZ7U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eHHeYwNNSUbChn+R5w80zEVFQE5yo7PWW6/QbKFvZ1BIEuSiCjWUp202iLUtlbMf/ 4cbj8a95Qr0u/BKSKi/W+ZRnjkaFdWGvTUA951Q15UgKb5f4idYwxUTdGh9YZX1jAp Oz+Cubc6knEoG5FM8gf+hmBvfVe8Ju4THqWx9MqIiw0E0YCncHNmpVEeajSzLSWbLK 8jCy3Ux6Gyx/NgJvBh1S0pVvJ0gHMBUpEWChWEUcnXhCYvlAgHpethE8NXOyTSlSef uHnOCFq4OPDLyAEoKWAm14VewDf+u+Uemdf/1MTFeYC9VWSetJ/rW/uDg65B5071wW l3AjV3ZSAVgJg== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments 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, 11 Feb 2015 21:41:26 -0000 On 2/11/15 2:26 PM, Christer Holmberg wrote: > ------------------------ > > * Section 3.3.2 > >>>> I suggest modifying the 2nd paragraph as follows: >>>> >>>> A CLUE entity MUST NOT use the partial reliability and limited >>>> retransmission extensions (defined in [RFC3758], enabled with >>>> the dcmap options 'max-retr' and 'max-time') for the CLUE >>>> data channel. >>>> >>>> (Otherwise this might be read to forbid using these for other data >>>> channels.) Mark also commented on this. >>> >>> Mark suggested the following text: >>> >>> "A CLUE data channel MUST NOT use the partial reliability and limited retransmission >>> SCTP extensions defined in [RFC3758]." >>> >>> Personally I would suggest to use Mark's text, and not talk about the dcmap options >>> in this section, which is about SCTP features and extensions. >> >> This may require some further discussion. >> >> In draft-ietf-rtcweb-data-channel there is a presumption that there is an API used >> for accessing data channels. The API makes the options appear to the user as being >> per-channel, even though in the SCTP protocol they are per-message. >> >> Similarly the ejzak draft negotiates them on a per-channel basis, and assumes that they will be used that way. >> >> I don't know if we are assuming that clue implementations will be using an API that preserves this >> per-channel behavior, or if we are assuming that the clue implementer will need to take the negotiated >> values and apply them on a per-message basis. > > I think we should not make assumptions what API is used. > > (Unfortunately, draft-data-channel seems to be focused mostly about browsers and WebRTC.) > >> The bottom line is that we prescribe which options must be negotiated for the clue channel, and then >> we require that the streams be used in a way that is consistent with those options. > > We could, odd a note, and inform people that according to [ref-to-data-channel] the SCTP options are applied per channel, i.e. to each message sent on a channel. Yes. > ------------------------- > > * Section 3.3.3 > >>>> I suggest revising this to read: >>>> >>>> A CLUE entity MUST use the ordered delivery SCTP service, as >>>> described in section 6.6 of [RFC4960]. This service is enabled >>>> either by omitting the 'ordered' option from the dcmap attribute, or >>>> by specifying 'ordered="1"' in the dcmap attribute. >>>> >>>> But this also keys into the other discussion of ordered. So make this conditional on that. >>> >>> Again, it'd like to keep the dcmap attribute details out of section 3.3, and make sure section 3.2 is clear enough. >>> >>> I have been thinking, though, whether it would be a good idea to switch the order of >>> sections 3.2 and 3.3, in order to first talk about the SCTP extensions etc, and then talk about how to signal them. >> >> Of course my comment above applies here too. > > Correct. > > However, it seems like your comment is not related to my suggestion of not talking about dcmap in section 3.3 :) > > Do you have an opinion on switching sections 3.2 and 3.3? Not specifically. But something needs to relate the two sections: the options used when sending messages need to be consistent with what is negotiated. Pretending that those two things are unrelated is confusing. Thanks, Paul From nobody Wed Feb 11 23:34:53 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F351A9110 for ; Wed, 11 Feb 2015 23:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhXKhoIcb3vH for ; Wed, 11 Feb 2015 23:34:50 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914841A3BA6 for ; Wed, 11 Feb 2015 23:34:49 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-bd-54dc579797b2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.7F.04231.7975CD45; Thu, 12 Feb 2015 08:34:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 08:34:46 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments Thread-Index: AdBF0hTQx0zvLBvrRLyWjvRWrr2JXwAMRhWAAArjG5AAAxccAAAWuiHA Date: Thu, 12 Feb 2015 07:34:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CE34A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> <54DB6EB1.7040006@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CD620@ESESSMB209.ericsson.se> <54DBCC7E.3090804@alum.mit.edu> In-Reply-To: <54DBCC7E.3090804@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje708DshBo29Ahb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRtfk1a8F02Yobp56zNzDOFO9i5OSQEDCR OPTyMiuELSZx4d56ti5GLg4hgSOMElMWfGOFcJYwSjz8dhEow8HBJmAh0f1PG6RBRMBTYsfH KcwgtrBAvMT+tilMICUiAgkSXWvSIUrcJP7cXsgIYrMIqEpMa7jHBmLzCvhKfG38zQIx/iqj xN1pH8GKOAV0JK6fuwc2kxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/6AeUJT4 +GofI0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcW F+emGxnrpRZlJhcX5+fp5aWWbGIExsnBLb91dzCufu14iFGAg1GJh7fQ/06IEGtiWXFl7iFG aQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYa7wvzf+yQsmQr6LXOrKwZcLP v58dnbZP9P1WyN9fu+lAQl3qdhOuWr37PPpP5pyZwzx9s82cJyyd7oKOedyrX/6VUz4oLfAy o2PX+7ex/mdents673TQxjqm76/112e3xUxuLS++Jjgh8CVPJ1Na1h+f+z+OOi9arzM5u9hg xo2YouUXX7pVKLEUZyQaajEXFScCAHorD1F0AgAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 07:34:52 -0000 Hi, ------------------------ * Section 3.3.2 >>>>> I suggest modifying the 2nd paragraph as follows: >>>>> >>>>> A CLUE entity MUST NOT use the partial reliability and limited >>>>> retransmission extensions (defined in [RFC3758], enabled with >>>>> the dcmap options 'max-retr' and 'max-time') for the CLUE >>>>> data channel. >>>>> >>>>> (Otherwise this might be read to forbid using these for other data >>>>> channels.) Mark also commented on this. >>>> >>>> Mark suggested the following text: >>>> >>>> "A CLUE data channel MUST NOT use the partial reliability and limited= retransmission >>>> SCTP extensions defined in [RFC3758]." >>>> >>>> Personally I would suggest to use Mark's text, and not talk about=20 >>>> the dcmap options in this section, which is about SCTP features and ex= tensions. >>> >>> This may require some further discussion. >>> >>> In draft-ietf-rtcweb-data-channel there is a presumption that there=20 >>> is an API used for accessing data channels. The API makes the options=20 >>> appear to the user as being per-channel, even though in the SCTP protoc= ol they are per-message. >>> >>> Similarly the ejzak draft negotiates them on a per-channel basis, and a= ssumes that they will be used that way. >>> >>> I don't know if we are assuming that clue implementations will be=20 >>> using an API that preserves this per-channel behavior, or if we are=20 >>> assuming that the clue implementer will need to take the negotiated val= ues and apply them on a per-message basis. >> >> I think we should not make assumptions what API is used. >> >> (Unfortunately, draft-data-channel seems to be focused mostly about=20 >> browsers and WebRTC.) >> >>> The bottom line is that we prescribe which options must be negotiated=20 >>> for the clue channel, and then we require that the streams be used in a= way that is consistent with those options. >> >> We could, odd a note, and inform people that according to [ref-to-data-c= hannel] the SCTP options are applied per channel, i.e. to each message sent= on a channel. > > Yes. Will be done. ------------------------- * Section 3.3.3 >>>>> I suggest revising this to read: >>>>> >>>>> A CLUE entity MUST use the ordered delivery SCTP service, as >>>>> described in section 6.6 of [RFC4960]. This service is enabled >>>>> either by omitting the 'ordered' option from the dcmap attribute= , or >>>>> by specifying 'ordered=3D"1"' in the dcmap attribute. >>>>> >>>>> But this also keys into the other discussion of ordered. So make this= conditional on that. >>>> >>>> Again, it'd like to keep the dcmap attribute details out of section 3.= 3, and make sure section 3.2 is clear enough. >>>> >>>> I have been thinking, though, whether it would be a good idea to=20 >>>> switch the order of sections 3.2 and 3.3, in order to first talk about= the SCTP extensions etc, and then talk about how to signal them. >>> >>> Of course my comment above applies here too. >> >> Correct. >> >> However, it seems like your comment is not related to my suggestion of=20 >> not talking about dcmap in section 3.3 :) >> >> Do you have an opinion on switching sections 3.2 and 3.3? > > Not specifically. But something needs to relate the two sections: the opt= ions used when sending messages need to be consistent with what is negotiat= ed. Pretending that those two things are unrelated is confusing. I agree. We could have a sentence in the SCTP considerations section, sayin= g something like: "Section 3.x describes how the SCTP properties and extens= ions are negotiated using the sdp-neg mechanism." Regards, Christer From nobody Thu Feb 12 02:47:13 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041911A8798 for ; Thu, 12 Feb 2015 02:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeoctehzvGzl for ; Thu, 12 Feb 2015 02:47:00 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BE91A1EF4 for ; Thu, 12 Feb 2015 02:46:59 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-64-54dc84a105b2 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.8B.04231.1A48CD45; Thu, 12 Feb 2015 11:46:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 11:46:57 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments Thread-Index: AdBF0hTQx0zvLBvrRLyWjvRWrr2JXwA3b85Q Date: Thu, 12 Feb 2015 10:46:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CF86C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje7CljshBi/e6FrsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGrDOrGAvOcFX0NUQ0MG7l6GLk5JAQMJF4 /2g2I4QtJnHh3nq2LkYuDiGBI4wS327cYYVwljBKdD/eytLFyMHBJmAh0f1PG6RBRKBeYv6x W2DNwgLxEvvbpjCBlIgIJEh0rUmHKDGSWDlxCQuIzSKgKjHn23dmkBJeAV+JaafEQcJCQGb3 uRtgUzgF/CT69+1lArEZgc75fmoNmM0sIC5x68l8JogzBSSW7DnPDGGLSrx8/I8VwlaU2Hm2 nRmiXkdiwe5PbBC2tsSyha/B4rwCghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi 3HQjY73Uoszk4uL8PL281JJNjMAIObjlt+4OxtWvHQ8xCnAwKvHwFvrfCRFiTSwrrsw9xCjN waIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2Penp1xPYvWfnFfczmL36R24qpr yw/MuPszZc4/nwmXmmav/Lj92ooGBd8pEwtCrKd7rii0tdOwDdtS5LtnhcshB6uT/nvaawO2 XJ1XnyR4TKHI4rVJ0w92k+fyT7s7909d+Tr+cou11e2Oq1kztVfpLJNWVD/GlZ/Mlxxy4mNT S/aCGSaM9+8osRRnJBpqMRcVJwIAR47LyHECAAA= Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 10:47:10 -0000 Hi, New suggestion on how to address one of Paul's comments. ------------------------- * Section 3.2.2 >> This starts with 'When the SDP-based "SCTP over DTLS" data channel negot= iation mechanism is used ...'. This suggests that there may be some other w= ay. How about: >> >> The SDP-based "SCTP over DTLS" data channel negotiation >> mechanism is used to establish a CLUE data channel. >> The values of the ... > > I'll fix as suggested. I suggest to only say: "The values of the SDP dcmap attribute [I-D.ietf-mmusic-data-channel-sdpne= g],=20 associated with the m- line describing the SCTPoDTLS association used to r= ealize=20 the WebRTC Data Channel, are set as following:" At the same time I suggest to modify the first paragraph in section 3.2.1. = to: "This section defines how to construct the SDP Media Description (m- line) for describing the SCTPoDTLS association used to realize a WebRTC Data Channel. The section also defines how to use the=20 SDP-based "SCTP over DTLS" data channel negotiation mechanism=20 [I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE Data=20 Channel on the SCTPoDTLS association." Because, as section 3.2.1 already says that the sdpneg mechanism is used, t= here is no need to repeat=20 that in section 3.2.2. Regards, Christer From nobody Thu Feb 12 03:10:35 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B821A8706 for ; Thu, 12 Feb 2015 03:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-I86E423_vS for ; Thu, 12 Feb 2015 03:09:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AACB1A87B8 for ; Thu, 12 Feb 2015 03:09:41 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-8e-54dc89f331bd Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6B.30.04076.3F98CD45; Thu, 12 Feb 2015 12:09:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0210.002; Thu, 12 Feb 2015 12:09:39 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments Thread-Index: AdBF0hTQx0zvLBvrRLyWjvRWrr2JXwAMRhWAAArjG5AAAxccAAAWuiHAAAdezMA= Date: Thu, 12 Feb 2015 11:09:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6CF9BA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6CABCB@ESESSMB209.ericsson.se> <54DB6EB1.7040006@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CD620@ESESSMB209.ericsson.se> <54DBCC7E.3090804@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CE34A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CE34A@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje7nzjshBo9vSlvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGyxlLmArmKFccmX+KpYGxQaaLkZNDQsBE Yvr2L2wQtpjEhXvrgWwuDiGBI4wSu1ceYYVwlgA5DSvYuxg5ONgELCS6/2mDNIgI1EvMP3aL EcQWFoiX2N82hQmkREQgQaJrTTpEiZ9E44RNYCUsAqoS31Z+YgexeQV8JV7P7oEaP5NJ4uSj jywgCU6ghuNT5jCB2IxAB30/tQbMZhYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0rsPNvO DFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFxbnp RkZ6qUWZycXF+Xl6eaklmxiBcXJwy2+rHYwHnzseYhTgYFTi4S3wvxMixJpYVlyZe4hRmoNF SZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGnwdvLqx5fvBgevq95TNnH2M0137w f7X1o8n52zm5Zz4+3CeUteS0CfdVxXDbKYcf7yi9urWCecvUM/yZ/yJWqCysalHJmf9IZZLP 5HXPzAOe7pngfCBB6OrDh9WbN/zWZpoxKYXnn7lB2WGtJw9vxrj56do/MNPcNjPR9+kKsUbO G0/eyJhrpimxFGckGmoxFxUnAgBMyuNndAIAAA== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 11:09:53 -0000 X-List-Received-Date: Thu, 12 Feb 2015 11:09:53 -0000 Hi, ------------------------ * Section 3.3.2 >>>>>> I suggest modifying the 2nd paragraph as follows: >>>>>> >>>>>> A CLUE entity MUST NOT use the partial reliability and limited >>>>>> retransmission extensions (defined in [RFC3758], enabled with >>>>>> the dcmap options 'max-retr' and 'max-time') for the CLUE >>>>>> data channel. >>>>>> >>>>>> (Otherwise this might be read to forbid using these for other data >>>>>> channels.) Mark also commented on this. >>>>> >>>>> Mark suggested the following text: >>>>> >>>>> "A CLUE data channel MUST NOT use the partial reliability and limite= d retransmission >>>>> SCTP extensions defined in [RFC3758]." >>>>> >>>>> Personally I would suggest to use Mark's text, and not talk about=20 >>>>> the dcmap options in this section, which is about SCTP features and e= xtensions. >>>> >>>> This may require some further discussion. >>>> >>>> In draft-ietf-rtcweb-data-channel there is a presumption that there=20 >>>> is an API used for accessing data channels. The API makes the=20 >>>> options appear to the user as being per-channel, even though in the SC= TP protocol they are per-message. >>>> >>>> Similarly the ejzak draft negotiates them on a per-channel basis, and = assumes that they will be used that way. >>>> >>>> I don't know if we are assuming that clue implementations will be=20 >>>> using an API that preserves this per-channel behavior, or if we are=20 >>>> assuming that the clue implementer will need to take the negotiated va= lues and apply them on a per-message basis. >>> >>> I think we should not make assumptions what API is used. >>> >>> (Unfortunately, draft-data-channel seems to be focused mostly about=20 >>> browsers and WebRTC.) >>> >>>> The bottom line is that we prescribe which options must be=20 >>>> negotiated for the clue channel, and then we require that the streams = be used in a way that is consistent with those options. >>> >>> We could, odd a note, and inform people that according to [ref-to-data-= channel] the SCTP options are applied per channel, i.e. to each message sen= t on a channel. >> >> Yes. > > Will be done. See my suggestion below, which should also cover this issue. ------------------------- * Section 3.3.3 >>>>>> I suggest revising this to read: >>>>>> >>>>>> A CLUE entity MUST use the ordered delivery SCTP service, as >>>>>> described in section 6.6 of [RFC4960]. This service is enabled >>>>>> either by omitting the 'ordered' option from the dcmap attribut= e, or >>>>>> by specifying 'ordered=3D"1"' in the dcmap attribute. >>>>>> >>>>>> But this also keys into the other discussion of ordered. So make thi= s conditional on that. >>>>> >>>>> Again, it'd like to keep the dcmap attribute details out of section 3= .3, and make sure section 3.2 is clear enough. >>>>> >>>>> I have been thinking, though, whether it would be a good idea to=20 >>>>> switch the order of sections 3.2 and 3.3, in order to first talk abou= t the SCTP extensions etc, and then talk about how to signal them. >>>> >>>> Of course my comment above applies here too. >>> >>> Correct. >>> >>> However, it seems like your comment is not related to my suggestion=20 >>> of not talking about dcmap in section 3.3 :) >>> >>> Do you have an opinion on switching sections 3.2 and 3.3? >> >> Not specifically. But something needs to relate the two sections: the op= tions used when sending messages need to be consistent with what is negotia= ted. Pretending that those two things are unrelated is confusing. > > I agree. We could have a sentence in the SCTP considerations section, say= ing something like: "Section 3.x describes how the SCTP properties and exte= nsions are negotiated using the sdp-neg mechanism." I suggest the following new SCTP considerations subsection: "3.2.1. General As described in [I-D.ietf-rtcweb-data-channel], different SCTP options (e.g. regarding ordered delivery ), can be used for a data channel. This section describes the SCTP options used for a CLUE data channel. Section 3.3 describes how SCTP options are signalled using SDP. NOTE: While SCTP allows SCTP options to be applied per SCTP message, [I-D.ietf-rtcweb-data-channel] mandates that, for a given data channel, the same SCTP options are applied to each SCTP message associated with that data channel." Regards, Christer From nobody Thu Feb 12 06:23:09 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BAF1A88E2 for ; Thu, 12 Feb 2015 06:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.302 X-Spam-Level: X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LIST=2.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 4nx3Q0eOIrsF for ; Thu, 12 Feb 2015 06:22:45 -0800 (PST) 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 003CA1A8872 for ; Thu, 12 Feb 2015 06:22:44 -0800 (PST) Received: from [216.82.254.20] by server-2.bemta-7.messagelabs.com id BC/CB-02992-437BCD45; Thu, 12 Feb 2015 14:22:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-47.messagelabs.com!1423750963!13053555!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16080 invoked from network); 12 Feb 2015 14:22:44 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-7.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 12 Feb 2015 14:22:44 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 12 Feb 2015 06:22:55 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 12 Feb 2015 06:22:42 -0800 Thread-Topic: [clue] short WGLC on draft-ietf-clue-framework-20 Thread-Index: AdBA4XKXikfXewLTTTir1FGhWdX6swF6Epuw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> In-Reply-To: <54D2C46E.1040700@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:22:54 -0000 Thanks Christian. My comments inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, February 04, 2015 8:17 PM > To: clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >=20 > Hello >=20 > Here are my last call comments: >=20 > 1. Section 1 Introduction: I think it would be good to add a sentence to > indicate that CLUE can be used in any multistream environment. It's not > just related to telepresence. [Duckworth, Mark] How about adding "This includes cases using multiple medi= a streams that are not necessarily telepresence." > 2. Section 4 1st para: "This section provides an overview of the > functional elements defined in this document to represent a telepresence > system". Like the above comment perhaps we could replace telepresence > with multistream? The section talks about different types of systems, > telepresence, webcam, multicast etc. CLUE can be applied to all of them. [Duckworth, Mark] How about "telepresence or multistream"? The spatial siz= e stuff can be useful for telepresence even without multistream. > 3. Section 5 pg14 2nd para: "The Consumer in the Endpoint receives the > information provided by the Provider, and can use it for two > purposes" The paragraph only talks about using the information for > constructing a Configure and for SDP. The provider can also use the > information for rendering decisions. It would be good to clarify this. [Duckworth, Mark] I think you mean the consumer can use the information for= rendering? How about saying "... can use it for three purposes" and then = add a sentence about rendering? > 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are > optional in the consumer and that it is free to ignore the information. > Whilst its true for the Advertisement I don't think this is generally > true. It shouldn't ignore the Options message. [Duckworth, Mark] I think it's okay the way it is. The protocol document h= as the details. > 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, > it means that whilst the Video Capture is not spatially related to any > other Video Capture". Is this true? Captures in the one scene ARE > spatially related. If the Area of capture is not included isn't the > Provider just saying that it can't provide specific details on the relati= on? [Duckworth, Mark] How about "If the Area of Capture is not specified, it me= ans the Video Capture is spatially related to other Captures in the same Sc= ene, but there is no detailed information on the relationship." > 6. Section 7.1.1.13: "This attribute is only applicable to video > Captures and presentation streams with visual information." Could this > also be applicable to audio captures? i.e. lyrics along with audio. [Duckworth, Mark] I don't remember why that restriction was added. Was tha= t in your original proposal for this attribute? It is okay with me to remo= ve this sentence. > 7. Section 7.2 Table 1: The table just lists "attributes" perhaps it > should distinguish between "MCC attributes" and "MC attributes" to > indicate the different scope. Also VCn should be aligned with the text > below the table that indicates VC3. [Duckworth, Mark] I agree > 8. Section 7.2.1.1 1st para: The actual number can be less "or equal to" > the maximum. [Duckworth, Mark] ok > 9. Section 12.1.1 Pg45: I think it would be good to add > "policy=3DSoundLevel" to MCC3 and MCC4 given that the descriptive text > indicates this function. [Duckworth, Mark] ok > 10. Section 12.1.1 Pg48: I think we need to add some text to explain > these parameters are not part of CLUE but are possible parameter that > can be assigned to encodings via SDP? This is mentioned in section > 12.1.2. Maybe we should move the text to the start of the example > section so that it applies to all sections. [Duckworth, Mark] I can clarify this. > 11. Section 12.3.1 Table14: It would be good to add "AllowSubset=3DTrue" > to MCC1 Just make it clear that the Provider allowed to choose. [Duckworth, Mark] ok > 12. Section 12.3.2 Table17: Incorrect table title, should be > "Advertisement set to Endpoint F". [Duckworth, Mark] Thanks. And there are two tables called 17. I'll fix th= e numbering. > 13. Section 12.3.3 Table 20: Incorrect table title, should be "...from > Endpoints E to G" [Duckworth, Mark] ok > 14. Section 7.2.14 Allow subset choice: Do we need to specify a default > behaviour if this is not included? We specify in other cases e.g. area > of capture what it means if not included. [Duckworth, Mark] It is not optional, so must be included. > I've sent the purely editorial ones to the author. >=20 > Regards, Christian >=20 > On 23/01/2015 8:20 PM, Roni Even wrote: > > > > Hi, > > > > There were good reviews during the WGLC on the framework document. > > > > Mark updated the document to include all the issues that were > > discussed in http://tools.ietf.org/html/draft-ietf-clue-framework-20 > > > > In order to verify that all concerns were addressed we will have a > > short WGLC till *February 4^th * and in there are no more open issues > > we will send the document to publication. > > > > Mark noted the following changes from 19 to 20: > > > > 1. Define term "CLUE" in introduction. > > > > 2. Add MCC attribute Allow Subset Choice. > > > > 3. Remove phrase about reducing SDP size, replace with > > > > potentially saving consumer resources. > > > > 4. Change example of a CLUE exchange that does not require SDP > > > > exchange. > > > > 5. Language attribute uses RFC5646. > > > > 6. Change Member person type to Attendee. Add Observer type. > > > > 7. Clarify DTLS/SRTP MUST be supported. > > > > 8. Change SHOULD NOT to MUST NOT regarding using xCard or > > > > description information for authorization decisions. > > > > 9. Clarify definition of Global View. > > > > 10. Refer to signaling doc regarding interoperating with a > > > > device that does not support CLUE. > > > > 11. Various minor editorial changes from working group last call > > > > feedback. > > > > 12. Capitalize defined terms. > > > > Thanks > > > > Roni Even > > > > CLUE co-chair > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Feb 12 06:33:32 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE84E1A88F3 for ; Thu, 12 Feb 2015 06:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id girB4Pd49RDI for ; Thu, 12 Feb 2015 06:33:26 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F571A88E2 for ; Thu, 12 Feb 2015 06:33:26 -0800 (PST) Received: from [216.82.241.100] by server-17.bemta-8.messagelabs.com id 58/8C-02755-5B9BCD45; Thu, 12 Feb 2015 14:33:25 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-220.messagelabs.com!1423751593!14045777!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22646 invoked from network); 12 Feb 2015 14:33:14 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-6.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 12 Feb 2015 14:33:14 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 12 Feb 2015 06:33:25 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Thu, 12 Feb 2015 06:33:11 -0800 Thread-Topic: [clue] short WGLC on draft-ietf-clue-framework-20 - Paul Thread-Index: AdBGz3m2oP4oW7ZQSqWuu4YI07/1Fw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C259@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: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Paul X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 14:33:28 -0000 Thanks Paul. My comments inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, February 05, 2015 12:19 PM > To: clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >=20 > I have just a few minor comments on this version: >=20 > Section 7.1.1.4: >=20 > The capture point of a static Capture MUST NOT move for the life of > the conference. >=20 > I don't think "conference" is the right word here. (The session might > not be a conference.) Perhaps "CLUE session" would work, though it is > not a defined term. [Duckworth, Mark] I think "conference" is fine. Or how about simply "The c= apture point of a static Capture MUST NOT change." > Section 7.1.1.11: >=20 > Again "conference is used where it might not be the right word. There > could be only two endpoints in the call, even if there are several > people at each end. And it is *possible* that there might be a Minute > Taker even if there were only two people in the call. So again perhaps > "session" or "CLUE session" would be better. [Duckworth, Mark] What's wrong with "conference"? I think a conference cou= ld have only two endpoints, or only two people. One of the definitions fro= m Merriam-webster: "a meeting of two or more persons for discussing matters= of common concern." > Section 7.2: >=20 > The MCC indicates that one or more Single Media Captures are > multiplexed (temporally and/or spatially) in one Media Capture. >=20 > The "temporally and/or spatially" works for video. Is that right for > audio? I guess "temporally" still applies, but does "spatially"? Maybe > it could if you have a stereo audio capture. But if you just mix the few > loudest speakers, what do you call that? >=20 > I don't have a suggestion about how to improve this. Does someone have a > suggestion? If not then this may be as good as we can do. [Duckworth, Mark] I think it is fine the way it is. Yes, multi-channel aud= io is spatial. Maybe this is a little better: "The MCC indicates that one = or more Single Media Captures are multiplexed (temporally and/or spatially)= or mixed in one Media Capture." Adding "mixed" covers that common audio c= ase. > Thanks, > Paul >=20 > On 1/23/15 4:20 AM, Roni Even wrote: > > Hi, > > > > There were good reviews during the WGLC on the framework document. > > > > Mark updated the document to include all the issues that were discussed > > in http://tools.ietf.org/html/draft-ietf-clue-framework-20 > > > > In order to verify that all concerns were addressed we will have a shor= t > > WGLC till *February 4^th * and in there are no more open issues we will > > send the document to publication. > > > > Mark noted the following changes from 19 to 20: > > > > 1. Define term "CLUE" in introduction. > > > > 2. Add MCC attribute Allow Subset Choice. > > > > 3. Remove phrase about reducing SDP size, replace with > > > > potentially saving consumer resources. > > > > 4. Change example of a CLUE exchange that does not require SDP > > > > exchange. > > > > 5. Language attribute uses RFC5646. > > > > 6. Change Member person type to Attendee. Add Observer type. > > > > 7. Clarify DTLS/SRTP MUST be supported. > > > > 8. Change SHOULD NOT to MUST NOT regarding using xCard or > > > > description information for authorization decisions. > > > > 9. Clarify definition of Global View. > > > > 10. Refer to signaling doc regarding interoperating with a > > > > device that does not support CLUE. > > > > 11. Various minor editorial changes from working group last call > > > > feedback. > > > > 12. Capitalize defined terms. > > > > Thanks > > > > Roni Even > > > > CLUE co-chair > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Feb 12 08:52:14 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81231A0177 for ; Thu, 12 Feb 2015 08:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myPP-5WcBNxr for ; Thu, 12 Feb 2015 08:52:11 -0800 (PST) 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.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D861A00F5 for ; Thu, 12 Feb 2015 08:52:10 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with comcast id rUrs1p0034xDoy801UsAWi; Thu, 12 Feb 2015 16:52:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id rUs91p00Q3Ge9ey01UsA38; Thu, 12 Feb 2015 16:52:10 +0000 Message-ID: <54DCDA39.3010902@alum.mit.edu> Date: Thu, 12 Feb 2015 11:52:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.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=1423759930; bh=TiFUP25ok4CbPo83ctNvqywREDCgk8UWuSctlMG+DSk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GY3MP85OwgJ3dyVPVjmt4HqyTBLL/6CRnqsoPE2tr22oG3vSY4wAaO08r72ZNE1Pd WTsYMb2qG6I3PrYgCnA8SngVunh7gWdpJXqs63LFExV/CUZC5KL/R+kn92qCYdEfRQ IJhxWSSnjVHvMRIN989413QJlB5tGOGkJNVdU9+OFifsPyrpy72sf3yG9FHg1Dc2QA SygmNQlSLbB3xMLzCNGRoTah3t4duw/HDvGIGfy+u19zj2RnPO/pry7LECTThORuiD W5hEwck+enwgAT5p4TNZFqVycm8aOC1jx71mwr7E4x33LJgOrR+rAjZs79gp16ESEA iDMAlIKnqfT0w== Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 16:52:12 -0000 On 2/12/15 9:22 AM, Duckworth, Mark wrote: >> 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, >> it means that whilst the Video Capture is not spatially related to any >> other Video Capture". Is this true? Captures in the one scene ARE >> spatially related. If the Area of capture is not included isn't the >> Provider just saying that it can't provide specific details on the relation? > [Duckworth, Mark] How about "If the Area of Capture is not specified, it means the Video Capture is spatially related to other Captures in the same Scene, but there is no detailed information on the relationship." Consider a scene containing two computer-generated powerpoint captures. The advertiser *could* include specific area of capture information if it wants to indicate how they should be presented relative to one another. But lacking that they really have no spatial relationship to one another, and the implication is that the receiver should make its own decision about how to present them. Thanks, Paul From nobody Thu Feb 12 09:03:07 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3381A012D for ; Thu, 12 Feb 2015 09:03:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFHeih7o_HMS for ; Thu, 12 Feb 2015 09:03:03 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7151A00F8 for ; Thu, 12 Feb 2015 09:03:03 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-10v.sys.comcast.net with comcast id rV2i1p0062TL4Rh01V33H2; Thu, 12 Feb 2015 17:03:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id rV321p00S3Ge9ey01V32BC; Thu, 12 Feb 2015 17:03:03 +0000 Message-ID: <54DCDCC5.3090507@alum.mit.edu> Date: Thu, 12 Feb 2015 12:03:01 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C259@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C259@CRPMBOXPRD08.polycom.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=1423760583; bh=CEVI7/sTEzpN3iB550bBgITKBQkM0ttPZ4tnklxgx38=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=neIUiElv8FJPflk4xb9E7BXWY0v2qaaUnfhKi9N03TJLzQrcC4ndQv6RmzsPgyh+7 OU8e7ILYEz807XhOUhZkMnVOV8pzaR92OdaLg9EuVG+JqVOyP9Ynhr2Fmgf6xhrM7r /H0cRVnGfuhhbdASdBLZlOExIW41SBFJXyVdZcoAVg8/x/TuLJGBfxpmeCQZlCz3jv 9/dTEi5mQvfVNWoh0X3gATNlcooUrolv1SykwHszYwsSXFInbtfLdPYQlTKtS1bhjJ qx/M//qc/imJKOQxbLBKX6BTWzjt0JI4RTakcvMGGtELU6Z2re7vM+civ3CEUhW01x Vy/3Y7VLWuopw== Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Paul X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 17:03:06 -0000 On 2/12/15 9:33 AM, Duckworth, Mark wrote: > Thanks Paul. > My comments inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Thursday, February 05, 2015 12:19 PM >> To: clue@ietf.org >> Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >> >> I have just a few minor comments on this version: >> >> Section 7.1.1.4: >> >> The capture point of a static Capture MUST NOT move for the life of >> the conference. >> >> I don't think "conference" is the right word here. (The session might >> not be a conference.) Perhaps "CLUE session" would work, though it is >> not a defined term. > [Duckworth, Mark] I think "conference" is fine. Or how about simply "The capture point of a static Capture MUST NOT change." Your last suggestion above doesn't work for me, because it doesn't indicate any bound on how long this must remain unchanged. I don't think "conference" works here because we have a specific definition of conference and this applies to clue sessions that aren't conferences according to that definition. I still think that replacing "conference" with "CLUE telepresence session" or just "telepresence session" would be appropriate. Those terms are used extensively in the protocol doc and mean the right thing, even though there is no formal definition of it. Perhaps we should add one. >> Section 7.1.1.11: >> >> Again "conference is used where it might not be the right word. There >> could be only two endpoints in the call, even if there are several >> people at each end. And it is *possible* that there might be a Minute >> Taker even if there were only two people in the call. So again perhaps >> "session" or "CLUE session" would be better. > [Duckworth, Mark] What's wrong with "conference"? I think a conference could have only two endpoints, or only two people. One of the definitions from Merriam-webster: "a meeting of two or more persons for discussing matters of common concern." See above. >> Section 7.2: >> >> The MCC indicates that one or more Single Media Captures are >> multiplexed (temporally and/or spatially) in one Media Capture. >> >> The "temporally and/or spatially" works for video. Is that right for >> audio? I guess "temporally" still applies, but does "spatially"? Maybe >> it could if you have a stereo audio capture. But if you just mix the few >> loudest speakers, what do you call that? >> >> I don't have a suggestion about how to improve this. Does someone have a >> suggestion? If not then this may be as good as we can do. > [Duckworth, Mark] I think it is fine the way it is. Yes, multi-channel audio is spatial. Maybe this is a little better: "The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) or mixed in one Media Capture." Adding "mixed" covers that common audio case. Your suggestion works for me. Thanks, Paul >> Thanks, >> Paul >> >> On 1/23/15 4:20 AM, Roni Even wrote: >>> Hi, >>> >>> There were good reviews during the WGLC on the framework document. >>> >>> Mark updated the document to include all the issues that were discussed >>> in http://tools.ietf.org/html/draft-ietf-clue-framework-20 >>> >>> In order to verify that all concerns were addressed we will have a short >>> WGLC till *February 4^th * and in there are no more open issues we will >>> send the document to publication. >>> >>> Mark noted the following changes from 19 to 20: >>> >>> 1. Define term "CLUE" in introduction. >>> >>> 2. Add MCC attribute Allow Subset Choice. >>> >>> 3. Remove phrase about reducing SDP size, replace with >>> >>> potentially saving consumer resources. >>> >>> 4. Change example of a CLUE exchange that does not require SDP >>> >>> exchange. >>> >>> 5. Language attribute uses RFC5646. >>> >>> 6. Change Member person type to Attendee. Add Observer type. >>> >>> 7. Clarify DTLS/SRTP MUST be supported. >>> >>> 8. Change SHOULD NOT to MUST NOT regarding using xCard or >>> >>> description information for authorization decisions. >>> >>> 9. Clarify definition of Global View. >>> >>> 10. Refer to signaling doc regarding interoperating with a >>> >>> device that does not support CLUE. >>> >>> 11. Various minor editorial changes from working group last call >>> >>> feedback. >>> >>> 12. Capitalize defined terms. >>> >>> Thanks >>> >>> Roni Even >>> >>> CLUE co-chair >>> >>> >>> >>> _______________________________________________ >>> 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 Feb 12 09:07:36 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEA81A0211 for ; Thu, 12 Feb 2015 09:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DlsJ_pCcjy2 for ; Thu, 12 Feb 2015 09:07:24 -0800 (PST) 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 DF2701A01AA for ; Thu, 12 Feb 2015 09:06:00 -0800 (PST) Received: from [216.82.254.19] by server-10.bemta-7.messagelabs.com id 79/8E-02756-77DDCD45; Thu, 12 Feb 2015 17:05:59 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-96.messagelabs.com!1423760758!14705136!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12425 invoked from network); 12 Feb 2015 17:05:59 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-7.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 12 Feb 2015 17:05:59 -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, 12 Feb 2015 09:06:09 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 12 Feb 2015 09:06:23 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Thu, 12 Feb 2015 09:05:56 -0800 Thread-Topic: [clue] short WGLC on draft-ietf-clue-framework-20 Thread-Index: AdBG5FS59ZdVmsgxQZacJoM0X9AsXAAAavIw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C29C@CRPMBOXPRD08.polycom.com> References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> <54DCDA39.3010902@alum.mit.edu> In-Reply-To: <54DCDA39.3010902@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 17:07:27 -0000 Hi Paul, So are you saying we should not make any change in the framework about this= ? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, February 12, 2015 11:52 AM > To: clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >=20 > On 2/12/15 9:22 AM, Duckworth, Mark wrote: >=20 > >> 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, > >> it means that whilst the Video Capture is not spatially related to any > >> other Video Capture". Is this true? Captures in the one scene ARE > >> spatially related. If the Area of capture is not included isn't the > >> Provider just saying that it can't provide specific details on the rel= ation? > > [Duckworth, Mark] How about "If the Area of Capture is not specified, i= t > means the Video Capture is spatially related to other Captures in the sam= e > Scene, but there is no detailed information on the relationship." >=20 > Consider a scene containing two computer-generated powerpoint captures. >=20 > The advertiser *could* include specific area of capture information if > it wants to indicate how they should be presented relative to one > another. But lacking that they really have no spatial relationship to > one another, and the implication is that the receiver should make its > own decision about how to present them. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Feb 12 09:31:38 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EB81A0372 for ; Thu, 12 Feb 2015 09:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-KBcdH3WPtA for ; Thu, 12 Feb 2015 09:31:34 -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 85B301A036C for ; Thu, 12 Feb 2015 09:31:33 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with comcast id rVXF1p0022S2Q5R01VXYfX; Thu, 12 Feb 2015 17:31:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-16v.sys.comcast.net with comcast id rVXY1p00C3Ge9ey01VXY0t; Thu, 12 Feb 2015 17:31:32 +0000 Message-ID: <54DCE372.6000004@alum.mit.edu> Date: Thu, 12 Feb 2015 12:31:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> <54DCDA39.3010902@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C29C@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C29C@CRPMBOXPRD08.polycom.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=1423762292; bh=7obKbLkOsJZ4oXjrEmcbzNPPoU2futuMKAGvtg+tu6c=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uqMEenNYF8S4lvtU7av8VzHgEgT05q5wD6yYCM77vECtlunLSkfGs1YHdLEqWdXMs cG4bBV3XNt0+1a+Jj92ygVgU0UiwQeS3YoggaXEXQikipTl8mbu2xTzKMGj0O/OZor /rMwoYMK6rxpdINrZBkD7iW2MxYZMC2ZganbxTKN0zl82rVNmKBbr3Mdlru+8/F3t0 4wMVXA9It6zseumJZBQawZxcgJEHuUQfvvFzZjEwzTavbdTRxZpJG5ySOMl11qYl3U viN6iT8jVIh4VuksuQMcwW1wuujLA5gQSf3ZcVPMip9nsdcZSRvacwUBpqgCWVzduQ zvBwkreGQuqAw== Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 17:31:36 -0000 On 2/12/15 12:05 PM, Duckworth, Mark wrote: > Hi Paul, > So are you saying we should not make any change in the framework about this? This is nit picking. I've made my point. I'll be satisfied with whatever you do. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Thursday, February 12, 2015 11:52 AM >> To: clue@ietf.org >> Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >> >> On 2/12/15 9:22 AM, Duckworth, Mark wrote: >> >>>> 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, >>>> it means that whilst the Video Capture is not spatially related to any >>>> other Video Capture". Is this true? Captures in the one scene ARE >>>> spatially related. If the Area of capture is not included isn't the >>>> Provider just saying that it can't provide specific details on the relation? >>> [Duckworth, Mark] How about "If the Area of Capture is not specified, it >> means the Video Capture is spatially related to other Captures in the same >> Scene, but there is no detailed information on the relationship." >> >> Consider a scene containing two computer-generated powerpoint captures. >> >> The advertiser *could* include specific area of capture information if >> it wants to indicate how they should be presented relative to one >> another. But lacking that they really have no spatial relationship to >> one another, and the implication is that the receiver should make its >> own decision about how to present them. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Feb 12 10:24:52 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142001A00FE for ; Thu, 12 Feb 2015 10:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_LIST=2.3, 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 rcPhtJnJUUtT for ; Thu, 12 Feb 2015 10:24:46 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (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 BB4CA1A1A40 for ; Thu, 12 Feb 2015 10:24:44 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w55so11884822wes.4 for ; Thu, 12 Feb 2015 10:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=1RPXxKYsxG/hkK9c2GdmaM9aSaMdk4Q/mCtJxZY9Mhc=; b=WPvtwZQ4jdrlp2o6xk/MSCEqbLoWvHZCriUIuVRSebNNwzQlBSVkpk1e/2+rhpUPV4 tq8uwA4Xzv4173FkqHi0ISIW7/CccdUvmwHykSXhYCjylwZpBoTJXgl68N40l04Jau2y 7K6IQHeBPIAsi8BzzJMMWtoLPA+ASiSUsY8p1R4f3nNXF93GhckZUOp0kPexKFz7DGD4 kABReEtB4L8TMCDbOvCZVZ3mudoJqSpPCZIfrshmh1WpkFj6UQFKoxOhDogsO12E/r+y LENjlpkdnhQba3EADG74uF8h24UqZBBFsiXnKd6WeA52gzA6MEz2PzDbor/cYAM3yYZx JOYw== X-Received: by 10.181.29.201 with SMTP id jy9mr8545868wid.17.1423765482446; Thu, 12 Feb 2015 10:24:42 -0800 (PST) Received: from RoniE (bzq-79-183-57-46.red.bezeqint.net. [79.183.57.46]) by mx.google.com with ESMTPSA id eg10sm2699153wib.5.2015.02.12.10.24.40 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Feb 2015 10:24:41 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Christian Groves'" , References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> Date: Thu, 12 Feb 2015 20:24:35 +0200 Message-ID: <009f01d046f1$29d39860$7d7ac920$@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: AQHtK3TkseeOLbojJnK0OSnn4PKnLQHFA9FZAYU9ao2cmTaF0A== Content-Language: en-us Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 18:24:49 -0000 Hi, > > 6. Section 7.1.1.13: "This attribute is only applicable to video > > Captures and presentation streams with visual information." Could this > > also be applicable to audio captures? i.e. lyrics along with audio. > [Duckworth, Mark] I don't remember why that restriction was added. Was that > in your original proposal for this attribute? It is okay with me to remove this > sentence. > Roni: This was discussed in IETF 90 and that was captured in the meeting notes. Also mentioned in Mark's email from September 5th, it was also discussed in the pre-WGLC on draft 15 and I think that Christian was OK for video only at the time. Regards Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: 12 February, 2015 4:23 PM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 > > Thanks Christian. > My comments inline. > Mark > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian > > Groves > > Sent: Wednesday, February 04, 2015 8:17 PM > > To: clue@ietf.org > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 > > > > Hello > > > > Here are my last call comments: > > > > 1. Section 1 Introduction: I think it would be good to add a sentence > > to indicate that CLUE can be used in any multistream environment. It's > > not just related to telepresence. > [Duckworth, Mark] How about adding "This includes cases using multiple media > streams that are not necessarily telepresence." > > > 2. Section 4 1st para: "This section provides an overview of the > > functional elements defined in this document to represent a > > telepresence system". Like the above comment perhaps we could replace > > telepresence with multistream? The section talks about different types > > of systems, telepresence, webcam, multicast etc. CLUE can be applied to all > of them. > [Duckworth, Mark] How about "telepresence or multistream"? The spatial size > stuff can be useful for telepresence even without multistream. > > > 3. Section 5 pg14 2nd para: "The Consumer in the Endpoint receives the > > information provided by the Provider, and can use it for two > > purposes" The paragraph only talks about using the information for > > constructing a Configure and for SDP. The provider can also use the > > information for rendering decisions. It would be good to clarify this. > [Duckworth, Mark] I think you mean the consumer can use the information for > rendering? How about saying "... can use it for three purposes" and then add a > sentence about rendering? > > > 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are > > optional in the consumer and that it is free to ignore the information. > > Whilst its true for the Advertisement I don't think this is generally > > true. It shouldn't ignore the Options message. > [Duckworth, Mark] I think it's okay the way it is. The protocol document has > the details. > > > 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, > > it means that whilst the Video Capture is not spatially related to any > > other Video Capture". Is this true? Captures in the one scene ARE > > spatially related. If the Area of capture is not included isn't the > > Provider just saying that it can't provide specific details on the relation? > [Duckworth, Mark] How about "If the Area of Capture is not specified, it means > the Video Capture is spatially related to other Captures in the same Scene, but > there is no detailed information on the relationship." > > > 6. Section 7.1.1.13: "This attribute is only applicable to video > > Captures and presentation streams with visual information." Could this > > also be applicable to audio captures? i.e. lyrics along with audio. > [Duckworth, Mark] I don't remember why that restriction was added. Was that > in your original proposal for this attribute? It is okay with me to remove this > sentence. > > > 7. Section 7.2 Table 1: The table just lists "attributes" perhaps it > > should distinguish between "MCC attributes" and "MC attributes" to > > indicate the different scope. Also VCn should be aligned with the text > > below the table that indicates VC3. > [Duckworth, Mark] I agree > > > 8. Section 7.2.1.1 1st para: The actual number can be less "or equal to" > > the maximum. > [Duckworth, Mark] ok > > > 9. Section 12.1.1 Pg45: I think it would be good to add > > "policy=SoundLevel" to MCC3 and MCC4 given that the descriptive text > > indicates this function. > [Duckworth, Mark] ok > > > 10. Section 12.1.1 Pg48: I think we need to add some text to explain > > these parameters are not part of CLUE but are possible parameter that > > can be assigned to encodings via SDP? This is mentioned in section > > 12.1.2. Maybe we should move the text to the start of the example > > section so that it applies to all sections. > [Duckworth, Mark] I can clarify this. > > > 11. Section 12.3.1 Table14: It would be good to add "AllowSubset=True" > > to MCC1 Just make it clear that the Provider allowed to choose. > [Duckworth, Mark] ok > > > 12. Section 12.3.2 Table17: Incorrect table title, should be > > "Advertisement set to Endpoint F". > [Duckworth, Mark] Thanks. And there are two tables called 17. I'll fix the > numbering. > > > 13. Section 12.3.3 Table 20: Incorrect table title, should be "...from > > Endpoints E to G" > [Duckworth, Mark] ok > > > 14. Section 7.2.14 Allow subset choice: Do we need to specify a > > default behaviour if this is not included? We specify in other cases > > e.g. area of capture what it means if not included. > [Duckworth, Mark] It is not optional, so must be included. > > > I've sent the purely editorial ones to the author. > > > > Regards, Christian > > > > On 23/01/2015 8:20 PM, Roni Even wrote: > > > > > > Hi, > > > > > > There were good reviews during the WGLC on the framework document. > > > > > > Mark updated the document to include all the issues that were > > > discussed in http://tools.ietf.org/html/draft-ietf-clue-framework-20 > > > > > > In order to verify that all concerns were addressed we will have a > > > short WGLC till *February 4^th * and in there are no more open > > > issues we will send the document to publication. > > > > > > Mark noted the following changes from 19 to 20: > > > > > > 1. Define term "CLUE" in introduction. > > > > > > 2. Add MCC attribute Allow Subset Choice. > > > > > > 3. Remove phrase about reducing SDP size, replace with > > > > > > potentially saving consumer resources. > > > > > > 4. Change example of a CLUE exchange that does not require SDP > > > > > > exchange. > > > > > > 5. Language attribute uses RFC5646. > > > > > > 6. Change Member person type to Attendee. Add Observer type. > > > > > > 7. Clarify DTLS/SRTP MUST be supported. > > > > > > 8. Change SHOULD NOT to MUST NOT regarding using xCard or > > > > > > description information for authorization decisions. > > > > > > 9. Clarify definition of Global View. > > > > > > 10. Refer to signaling doc regarding interoperating with a > > > > > > device that does not support CLUE. > > > > > > 11. Various minor editorial changes from working group last > > > call > > > > > > feedback. > > > > > > 12. Capitalize defined terms. > > > > > > Thanks > > > > > > Roni Even > > > > > > CLUE co-chair > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Feb 13 04:37:14 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B461A1BFA; Fri, 13 Feb 2015 04:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rY02UsTXRlVZ; Fri, 13 Feb 2015 04:37:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8521A1BA7; Fri, 13 Feb 2015 04:37:09 -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: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150213123709.15687.60490.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 04:37:09 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-datachannel-08.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 12:37:12 -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-08.txt Pages : 13 Date : 2015-02-13 Abstract: This document defines how to use the WebRTC Data Channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-datachannel-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-datachannel-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 13 04:40:37 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048B41A1BFA for ; Fri, 13 Feb 2015 04:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYII5BxX6MOV for ; Fri, 13 Feb 2015 04:40:33 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B521A1B27 for ; Fri, 13 Feb 2015 04:40:30 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-2b-54ddf0bc35b6 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 09.B7.04484.CB0FDD45; Fri, 13 Feb 2015 13:40:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 13:40:28 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Draft new version: draft-clue-data-channel Thread-Index: AdBHid0N3cv2n+beRq65ob3eyClJhA== Date: Fri, 13 Feb 2015 12:40:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D1A75@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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6D1A75ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje6eD3dDDBZPt7DYf+oyswOjx5Il P5kCGKO4bFJSczLLUov07RK4MuZvbmEr2ClX8ebnFqYGxntSXYycHBICJhJLJx5ihbDFJC7c W8/WxcjFISRwhFHiVsMTKGcJo8ST3n1ADgcHm4CFRPc/bZAGEQFliaOb+9lAbGEBY4k/s2cx Q8QtJJYu+sAKYetJfJr+ixWklUVAVaJjlhlImFfAV6KncwETiM0ItPf7qTVgNrOAuMStJ/OZ IO4RkFiy5zwzhC0q8fLxP6g7FSV2nm1nhqjPl7iz4hoLxExBiZMzn7BMYBSahWTULCRls5CU QcR1JBbs/sQGYWtLLFv4mhnGPnPgMROy+AJG9lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsY gRFxcMtvgx2ML587HmIU4GBU4uHdmHE3RIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjKIGy3bPYJn09vBE94c6r1zSth/y3r9ZbI+2PWtD2avqFelntZQV 4/m4f8jmbbV11Zj3bHXXjfvJ979Kl7r8Vr9cnvuLyWIPt/3/J1reVusunUm2sbpxmmHToyAO 8wXfRGoOcj8on+O4r945V21G7tYjpscqLXLO189odH5qybV90pctyzuazyuxFGckGmoxFxUn AgDR7mLVaQIAAA== Archived-At: Subject: [clue] Draft new version: draft-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: Fri, 13 Feb 2015 12:40:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6D1A75ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am going to be out of office next week, so based on the WGLC comments so = far I've submitted a new version (-08) of the CLUE data channel draft. Plea= se let me know if I've forgotten to address some comment(s). Note that I have removed the IANA consideration for the dcmap protocol valu= e, assuming we will use the protocol value registered to the WebSocket prot= ocol registry. I am also using the ordered=3D"true" value, based on the discussions on the= MMUSIC list. But, if that changes, I will obviously align. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D6D1A75ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am going to be out of office = next week, so based on the WGLC comments so far I’ve submitted a new = version (-08) of the CLUE data channel draft. Please let me know if I’= ;ve forgotten to address some comment(s).

 

Note that I have removed the IA= NA consideration for the dcmap protocol value, assuming we will use the pro= tocol value registered to the WebSocket protocol registry.

 

I am also using the ordered=3D&= #8221;true” value, based on the discussions on the MMUSIC list. But, = if that changes, I will obviously align.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D6D1A75ESESSMB209erics_-- From nobody Fri Feb 13 05:44:33 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223201A1B27 for ; Fri, 13 Feb 2015 05:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMtFNH2ie6Qs for ; Fri, 13 Feb 2015 05:44:29 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (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 9B22F1A1F04 for ; Fri, 13 Feb 2015 05:44:28 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x3so16715977wes.6 for ; Fri, 13 Feb 2015 05:44:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/D5mTbMYJE3KThveNqiocQSkhu3Q1j0B+3rxyXD9olg=; b=iboBemY/JK1fmq60//t0LS0K9PKwCUJix9+1A5560aT4BFStQT8/LfIFZ2ty1C8ytx SW2PCqG5J+kCwcvgjU35/+Pfgf+gQ8t9Iy0twplCNki6qzNvV/1zjZGfdbaqevQeBIW8 doR3HqFSvB2aWVXmtYND0t2Gcxf6WIGJ+F7+H0mMzZoGE9Uy2J6Shk6PBJIT4uxwNXVa qwRB3aEuv6q/fFnQrXjtkFt05c6u4Z29AznuSlm8KDsQUz31CQ0Be/p3r4Bv1BN4tH70 qlIjSeUnbD6z457/6T9zfTCQXkT4FWxyBfnP1l5b4oc5TGvNTEkE/05WUXh37HJmuY6D OZ0Q== MIME-Version: 1.0 X-Received: by 10.181.13.4 with SMTP id eu4mr16481166wid.41.1423835067307; Fri, 13 Feb 2015 05:44:27 -0800 (PST) Received: by 10.194.120.167 with HTTP; Fri, 13 Feb 2015 05:44:27 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D1A75@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1A75@ESESSMB209.ericsson.se> Date: Fri, 13 Feb 2015 08:44:27 -0500 Message-ID: From: Daniel Burnett To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d043be15267dc1e050ef86f16 Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Draft new version: draft-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: Fri, 13 Feb 2015 13:44:32 -0000 --f46d043be15267dc1e050ef86f16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Christer. All, the WGLC is still open through the end of today, so if you have any comments on draft 07 or on the new 08, please do go ahead and get them in today. I'm sure Christer will still do his best to address them when he returns. -- dan On Fri, Feb 13, 2015 at 7:40 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I am going to be out of office next week, so based on the WGLC comments s= o > far I=E2=80=99ve submitted a new version (-08) of the CLUE data channel d= raft. > Please let me know if I=E2=80=99ve forgotten to address some comment(s). > > > > Note that I have removed the IANA consideration for the dcmap protocol > value, assuming we will use the protocol value registered to the WebSocke= t > protocol registry. > > > > I am also using the ordered=3D=E2=80=9Dtrue=E2=80=9D value, based on the = discussions on the > MMUSIC list. But, if that changes, I will obviously align. > > > > Regards, > > > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --f46d043be15267dc1e050ef86f16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Christer.=C2=A0

All, the WGLC is still= open through the end of today, so if you have any comments on draft 07 or = on the new 08, please do go ahead and get them in today.=C2=A0 I'm sure= Christer will still do his best to address them when he returns.

-- dan


On Fri, Feb 13, 2015 at 7:40 AM, Christer Holmberg <ch= rister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

I am going to be out of office = next week, so based on the WGLC comments so far I=E2=80=99ve submitted a ne= w version (-08) of the CLUE data channel draft. Please let me know if I=E2= =80=99ve forgotten to address some comment(s).

=C2=A0

Note that I have removed the IA= NA consideration for the dcmap protocol value, assuming we will use the pro= tocol value registered to the WebSocket protocol registry.

=C2=A0

I am also using the ordered=3D= =E2=80=9Dtrue=E2=80=9D value, based on the discussions on the MMUSIC list. = But, if that changes, I will obviously align.

=C2=A0

Regards,=

=C2=A0

Christer


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


--f46d043be15267dc1e050ef86f16-- From nobody Fri Feb 13 06:03:03 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51A1A8035 for ; Fri, 13 Feb 2015 06:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVscBqvLIIyG for ; Fri, 13 Feb 2015 06:02:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346561A70FF for ; Fri, 13 Feb 2015 06:02:40 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-98-54de03fde42d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2A.58.04484.DF30ED45; Fri, 13 Feb 2015 15:02:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 15:02:37 +0100 From: Christer Holmberg To: Daniel Burnett Thread-Topic: [clue] Draft new version: draft-clue-data-channel Thread-Index: AdBHid0N3cv2n+beRq65ob3eyClJhAAAPBOAAAKxG3A= Date: Fri, 13 Feb 2015 14:02:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D1F23@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D1A75@ESESSMB209.ericsson.se> 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.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6D1F23ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGfG3Rvcf870Qg87TXBb7T11mtti4U9uB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyuiZs5OxoCWhYsq9jAbGLbFdjJwcEgImEn8W NTND2GISF+6tZ+ti5OIQEjjCKPF4+3dmCGcJo8Srv5sZuxg5ONgELCS6/2mDNIgI6Ep8fDEX rJlZQFnia8MmJhBbWMBO4uzM+UwQNfYSc2YdYoGwrSQmfpzABjKGRUBVom1BMkiYV8BXYsLV Rqi9UxglGg7cZQWp4RQIlHi7wxikhhHotu+n1jBBrBKXuPUEYryEgIDEkj3noe4XlXj5+B8r hK0osfNsO9Rp+RLLbi1jhdglKHFy5hOWCYyis5CMmoWkbBaSsllAVzALaEqs36UPUaIoMaX7 ITuErSHROmcuO7L4Akb2VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBcXZwy2+DHYwvnzse YhTgYFTi4d2YcTdEiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MlnzxciyeVRzzBWrKvMJZmXemhm77tlzb8OvrrSfavrxZqXWj/HD45+/mrNtVLrvG9n6o iJroIXzpfIXZpEMn5Ht+p2pyzExd6Ci1PFLzRoIM+2vfDXfDfG/ll/Y4+FUHWqiG2AZd8FvF q61uf4n/ps1TC/204F+irLM+PLjuNte0izXMzluJpTgj0VCLuag4EQD3VcTHlAIAAA== Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Draft new version: draft-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: Fri, 13 Feb 2015 14:03:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6D1F23ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFsbCBjaGFuZ2VzIChleGNlcHQgZm9yIHJlZmVyZW5jZSB1cGRhdGVzKSBpbiAtMDgg YXJlIGJhc2VkIG9uIHRoZSBXR0xDIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZhciwgc28gaWYgeW91 IGRvbuKAmXQgbGlrZSB0aGUgd2F5IHNvbWV0aGluZyBoYXMgYmVlbiBjaGFuZ2VkLCBwbGVhc2Ug bG9vayBmb3IgdGhlIGFzc29jaWF0ZWQgZS1tYWlsIHRocmVhZCBhbmQgcHJvdmlkZSB5b3VyIGlu cHV0IHRoZXJlIDopDQoNClRoYW5rcyENCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTog RGFuaWVsIEJ1cm5ldHQgW21haWx0bzpkYW5pZWxjYnVybmV0dEBnbWFpbC5jb21dDQpTZW50OiAx My4gaGVsbWlrdXV0YSAyMDE1IDE1OjQ0DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcNCkNjOiBjbHVl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2NsdWVdIERyYWZ0IG5ldyB2ZXJzaW9uOiBkcmFmdC1j bHVlLWRhdGEtY2hhbm5lbA0KDQpUaGFua3MgQ2hyaXN0ZXIuDQoNCkFsbCwgdGhlIFdHTEMgaXMg c3RpbGwgb3BlbiB0aHJvdWdoIHRoZSBlbmQgb2YgdG9kYXksIHNvIGlmIHlvdSBoYXZlIGFueSBj b21tZW50cyBvbiBkcmFmdCAwNyBvciBvbiB0aGUgbmV3IDA4LCBwbGVhc2UgZG8gZ28gYWhlYWQg YW5kIGdldCB0aGVtIGluIHRvZGF5LiAgSSdtIHN1cmUgQ2hyaXN0ZXIgd2lsbCBzdGlsbCBkbyBo aXMgYmVzdCB0byBhZGRyZXNzIHRoZW0gd2hlbiBoZSByZXR1cm5zLg0KLS0gZGFuDQoNCk9uIEZy aSwgRmViIDEzLCAyMDE1IGF0IDc6NDAgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4+IHdyb3RlOg0KSGksDQoNCkkgYW0gZ29pbmcgdG8gYmUgb3V0IG9mIG9mZmljZSBuZXh0IHdl ZWssIHNvIGJhc2VkIG9uIHRoZSBXR0xDIGNvbW1lbnRzIHNvIGZhciBJ4oCZdmUgc3VibWl0dGVk IGEgbmV3IHZlcnNpb24gKC0wOCkgb2YgdGhlIENMVUUgZGF0YSBjaGFubmVsIGRyYWZ0LiBQbGVh c2UgbGV0IG1lIGtub3cgaWYgSeKAmXZlIGZvcmdvdHRlbiB0byBhZGRyZXNzIHNvbWUgY29tbWVu dChzKS4NCg0KTm90ZSB0aGF0IEkgaGF2ZSByZW1vdmVkIHRoZSBJQU5BIGNvbnNpZGVyYXRpb24g Zm9yIHRoZSBkY21hcCBwcm90b2NvbCB2YWx1ZSwgYXNzdW1pbmcgd2Ugd2lsbCB1c2UgdGhlIHBy b3RvY29sIHZhbHVlIHJlZ2lzdGVyZWQgdG8gdGhlIFdlYlNvY2tldCBwcm90b2NvbCByZWdpc3Ry eS4NCg0KSSBhbSBhbHNvIHVzaW5nIHRoZSBvcmRlcmVkPeKAnXRydWXigJ0gdmFsdWUsIGJhc2Vk IG9uIHRoZSBkaXNjdXNzaW9ucyBvbiB0aGUgTU1VU0lDIGxpc3QuIEJ1dCwgaWYgdGhhdCBjaGFu Z2VzLCBJIHdpbGwgb2J2aW91c2x5IGFsaWduLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2x1ZSBtYWls aW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmc8bWFpbHRvOmNsdWVAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCg0K --_000_7594FB04B1934943A5C02806D1A2204B1D6D1F23ESESSMB209erics_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxl LW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbGwgY2hhbmdlcyAoZXhjZXB0IGZvciByZWZl cmVuY2UgdXBkYXRlcykgaW4gLTA4IGFyZSBiYXNlZCBvbiB0aGUgV0dMQyBjb21tZW50cyByZWNl aXZlZCBzbyBmYXIsIHNvIGlmIHlvdSBkb27igJl0IGxpa2UgdGhlIHdheSBzb21ldGhpbmcgaGFz IGJlZW4NCiBjaGFuZ2VkLCBwbGVhc2UgbG9vayBmb3IgdGhlIGFzc29jaWF0ZWQgZS1tYWlsIHRo cmVhZCBhbmQgcHJvdmlkZSB5b3VyIGlucHV0IHRoZXJlIDopPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhbmllbCBCdXJuZXR0IFttYWlsdG86ZGFuaWVsY2J1 cm5ldHRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDEzLiBoZWxtaWt1dXRhIDIwMTUg MTU6NDQ8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+Q2M6PC9iPiBj bHVlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbY2x1ZV0gRHJhZnQgbmV3IHZl cnNpb246IGRyYWZ0LWNsdWUtZGF0YS1jaGFubmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtzIENo cmlzdGVyLiZuYnNwOyA8YnI+DQo8YnI+DQpBbGwsIHRoZSBXR0xDIGlzIHN0aWxsIG9wZW4gdGhy b3VnaCB0aGUgZW5kIG9mIHRvZGF5LCBzbyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMgb24gZHJh ZnQgMDcgb3Igb24gdGhlIG5ldyAwOCwgcGxlYXNlIGRvIGdvIGFoZWFkIGFuZCBnZXQgdGhlbSBp biB0b2RheS4mbmJzcDsgSSdtIHN1cmUgQ2hyaXN0ZXIgd2lsbCBzdGlsbCBkbyBoaXMgYmVzdCB0 byBhZGRyZXNzIHRoZW0gd2hlbiBoZSByZXR1cm5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPi0tIGRhbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIg MTMsIDIwMTUgYXQgNzo0MCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIGdvaW5nIHRvIGJlIG91dCBvZiBvZmZp Y2UgbmV4dCB3ZWVrLCBzbyBiYXNlZCBvbiB0aGUgV0dMQyBjb21tZW50cyBzbyBmYXIgSeKAmXZl IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uICgtMDgpIG9mIHRoZSBDTFVFIGRhdGEgY2hhbm5lbCBk cmFmdC4gUGxlYXNlIGxldCBtZQ0KIGtub3cgaWYgSeKAmXZlIGZvcmdvdHRlbiB0byBhZGRyZXNz IHNvbWUgY29tbWVudChzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3RlIHRoYXQgSSBoYXZl IHJlbW92ZWQgdGhlIElBTkEgY29uc2lkZXJhdGlvbiBmb3IgdGhlIGRjbWFwIHByb3RvY29sIHZh bHVlLCBhc3N1bWluZyB3ZSB3aWxsIHVzZSB0aGUgcHJvdG9jb2wgdmFsdWUgcmVnaXN0ZXJlZCB0 byB0aGUgV2ViU29ja2V0IHByb3RvY29sIHJlZ2lzdHJ5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PkkgYW0gYWxzbyB1c2luZyB0aGUgb3JkZXJlZD3igJ10cnVl4oCdIHZhbHVlLCBiYXNlZCBvbiB0 aGUgZGlzY3Vzc2lvbnMgb24gdGhlIE1NVVNJQyBsaXN0LiBCdXQsIGlmIHRoYXQgY2hhbmdlcywg SSB3aWxsIG9idmlvdXNseSBhbGlnbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5DaHJpc3Rlcjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpjbHVlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjbHVlQGlldGYu b3JnIj5jbHVlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B1D6D1F23ESESSMB209erics_-- From nobody Fri Feb 13 09:48:52 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF71A00BD for ; Fri, 13 Feb 2015 09:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RI3ZyFUue_k for ; Fri, 13 Feb 2015 09:48:50 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1E01A006F for ; Fri, 13 Feb 2015 09:48:50 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-03v.sys.comcast.net with comcast id rtok1p0022Udklx01topnS; Fri, 13 Feb 2015 17:48:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id rtop1p0063Ge9ey01topPV; Fri, 13 Feb 2015 17:48:49 +0000 Message-ID: <54DE3900.7030505@alum.mit.edu> Date: Fri, 13 Feb 2015 12:48:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54D98C0B.9040307@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D6C05D5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6C05D5@ESESSMB209.ericsson.se> 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=1423849729; bh=4sh5Cbvcy0R7Vmet8PeiGK5BvAh9o2AKCNaRC9W8DMU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FgCPByir29lUUeLn9xIQL6e+2EHkBIlIvxQQXvRK+KYRzRPEVIpNUw4Lt+dtHOZ7+ XbRuNx9IOIqo3h4rwxcmu4f27ZOKaVTZpXFolmvqqGMO59BQQ43jd2HWh2gdBZP2yR gqzXjO1gfYpJpiJJw0clT2F0HAb4/YQwV3/K8xVcoJJzGKjm3YRfYIvqbDQKvIo2v9 6E1XHujG68bmBu5tG3pB4btzO6t4Oqqnh5RxCGYcalnhK3XdnKeeRHjVSph6HzT/cY EVrBLtq4Lc6m6P6uwktE+/xyXvAMlfV5FyHQJz++2aDVTI0oBvDddfFGGVWnn3yiWu C6wTxcAIJ7r+A== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:48:51 -0000 On 2/10/15 2:24 AM, Christer Holmberg wrote: > Hi, > >>>>> 2. Section 3.2.1.1: Given that the general feeling is that UDP will >>>>> be more common than TCP do we want to make a recommendation on what >>>>> transport CLUE endpoint should support in order to maximise interop? >>>> I guess we could say that TCP SHOULD only be used if needed for ICE purpose. >>>> >>>> But, I'd like to make sure other are ok with such approach too. >>> What about adding the following text: >>> >>> "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association used to realize >>> the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless >>> the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used and >>> the ICE procedures determines that TCP transport is required." >> [CNG] I think there's one "the" too many in the first line. Should it read "CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize..."? > > Correct. I'll fix that. It is corrected in -08. But after thinking about it further, I think should not restrict this usage to ICE. There may be other circumstances when it is known that UDP won't work. So how about: CLUE entities SHOULD NOT transport the SCTPoDTLS association used to realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" proto value), unless it is known that UDP/DTLS/SCTP will not work. (For instance, when the the Interactive Connectivity Establishment (ICE) mechanism [RFC5245] is used and the ICE procedures determine that TCP transport is required.) Thanks, Paul From nobody Fri Feb 13 09:59:38 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EDF1A020B for ; Fri, 13 Feb 2015 09:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_111=0.6, 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 1rm-X7mtuk-x for ; Fri, 13 Feb 2015 09:59:34 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [69.252.207.37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 923481A0102 for ; Fri, 13 Feb 2015 09:59:34 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-05v.sys.comcast.net with comcast id rtyw1p00C2Bo0NV01tzZ5V; Fri, 13 Feb 2015 17:59:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id rtzY1p00E3Ge9ey01tzYsW; Fri, 13 Feb 2015 17:59:33 +0000 Message-ID: <54DE3B83.9040305@alum.mit.edu> Date: Fri, 13 Feb 2015 12:59:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54DA8EFF.8090302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CAADC@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6CAADC@ESESSMB209.ericsson.se> 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=1423850373; bh=txWrt4A0wZ1N28sLrgeJ3m0tvSRkpnuHTuQN5GN/G98=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mn8HQVWH2ysRkz68vuEj5UQnqPB7gdCvNlaPF4c/kKExnJXv1cCG1mz1w+d5+Ch5l CE8w5iZkvG6yxeF8UihIfropA0bjWi0am5C4mXipSd7WLKO2X0Nta2cl30IaO1Xqda AjAw5G/3UNuSCyvE2CBQqM0Qa5Z7AZ9Z3ejoP5O4mXsgiXjrQfU/0OqxcoNkdpFuiX gAVViWNOpRP0pv99MI6frelq/OOX4yLrDoN/RXLyylkq61PT/irZwVdGe5VlOqANsV R2a7FsYgn9HbKbJj+JIoNyurHFZ9lH7dQAPfH8VqgpUClmL8gRvDCXLFZJQs6rPp8b 1CLfEEYbsZtFQ== Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 17:59:36 -0000 On 2/11/15 3:06 AM, Christer Holmberg wrote: >>> What about adding the following text: >>> >>> "NOTE: As CLUE entities are required to use ordered SCTP message delivery, >>> with full reliability, according to the procedures in [I-D.ietf-mmusic-data-channel-sdpneg] >>> the ordered, max-retr and max-time attribute parameters are not used when >>> negotiating CLUE data channels." >> >> This is good, except that we should not exclude the possibility of explicitly specifying reliable ordered delivery, by including 'ordered' >> with the appropriate value. (I can't tell whether that is "0" or "1". >> Right how the text defines them both as meaning ordered.) > > Correct. I'm ok with table 2 now. But I think it would be good for the example in 3.3.4 (table 1) to show the use of the ordered attribute: m=application 54111 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port: 5000 a=dcmap:2 subprotocol="CLUE";ordered=true That doesn't depend on the default value for ordered. Thanks, Paul From nobody Fri Feb 13 10:01:40 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E9E1A8765 for ; Fri, 13 Feb 2015 10:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, 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 WD59rqUDry2g for ; Fri, 13 Feb 2015 10:01:35 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [69.252.207.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC82C1A8781 for ; Fri, 13 Feb 2015 10:01:31 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-02v.sys.comcast.net with comcast id ru191p0082EPM3101u1WLQ; Fri, 13 Feb 2015 18:01:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id ru1W1p0023Ge9ey01u1Wdv; Fri, 13 Feb 2015 18:01:30 +0000 Message-ID: <54DE3BFA.2050908@alum.mit.edu> Date: Fri, 13 Feb 2015 13:01:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D6D1A75@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6D1F23@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D1F23@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=1423850490; bh=ZdD0HVED/57XRvp6RCog4hVIGAVrg4XfhIvGMjNtqNg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K1YXpcdqQ+bvnPEx56EHfXdb3kwyN5S7P1yAdfNJDgWrs5TF6fI/L4IKPJO1y0xNr R/6JIAKdEtIjWSwfIfDdZREj6Fpkjf4AUiFGUF9HTvSqAI0fxcfso6Zd3NvA3rTX3T Ozyu7UVMRWhBOiMx1Pf5x7aWsqT5fyyf+QHgH/23raSHaL7lek+rm1RwNqc8OKVBIJ mnOU7+gJGn5z2H6ljhSxsMWrFmd/yRnfd9AFsr5RbSE+MSxGoFWQOn5yT+weDxpoEQ Btck81B+Bm93HK1APBO74QnlvdGhsyBiLLWexSZuFJa1CxW7cTfmC/HqHWNMKEe0BG HFBe0gPvtTaoQ== Archived-At: Subject: Re: [clue] Draft new version: draft-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: Fri, 13 Feb 2015 18:01:37 -0000 On 2/13/15 9:02 AM, Christer Holmberg wrote: > Hi, > > All changes (except for reference updates) in -08 are based on the WGLC > comments received so far, so if you don’t like the way something has > been changed, please look for the associated e-mail thread and provide > your input there :) OK. I reviewed the changes, and commented by replying to a couple of earlier messages. Otherwise it seems good. Thanks, Paul > Thanks! > > Regards, > > Christer > > *From:*Daniel Burnett [mailto:danielcburnett@gmail.com] > *Sent:* 13. helmikuuta 2015 15:44 > *To:* Christer Holmberg > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Draft new version: draft-clue-data-channel > > Thanks Christer. > > All, the WGLC is still open through the end of today, so if you have any > comments on draft 07 or on the new 08, please do go ahead and get them > in today. I'm sure Christer will still do his best to address them when > he returns. > > -- dan > > On Fri, Feb 13, 2015 at 7:40 AM, Christer Holmberg > > > wrote: > > Hi, > > I am going to be out of office next week, so based on the WGLC comments > so far I’ve submitted a new version (-08) of the CLUE data channel > draft. Please let me know if I’ve forgotten to address some comment(s). > > Note that I have removed the IANA consideration for the dcmap protocol > value, assuming we will use the protocol value registered to the > WebSocket protocol registry. > > I am also using the ordered=”true” value, based on the discussions on > the MMUSIC list. But, if that changes, I will obviously align. > > 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 Fri Feb 13 10:25:44 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6681A00E6 for ; Fri, 13 Feb 2015 10:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_74=0.6, 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 97J8739BvVk5 for ; Fri, 13 Feb 2015 10:25:40 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 659201A00BD for ; Fri, 13 Feb 2015 10:25:40 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id F3C542735D7DD; Fri, 13 Feb 2015 18:25:34 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t1DIPbou004145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Feb 2015 13:25:37 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 13 Feb 2015 13:25:37 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Paul Kyzivat , Christer Holmberg , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAHUKDIAAEslKEACF7y+AAAms76A= Date: Fri, 13 Feb 2015 18:25:36 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54DA8EFF.8090302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CAADC@ESESSMB209.ericsson.se> <54DE3B83.9040305@alum.mit.edu> In-Reply-To: <54DE3B83.9040305@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 18:25:42 -0000 > I'm ok with table 2 now. But I think it would be good for the example in > 3.3.4 (table 1) to show the use of the ordered attribute: >=20 > m=3Dapplication 54111 UDP/DTLS/SCTP webrtc-datachannel > a=3Dsctp-port: 5000 > a=3Ddcmap:2 subprotocol=3D"CLUE";ordered=3Dtrue >=20 > That doesn't depend on the default value for ordered. [Raju] Proposed default is ordered=3Dtrue. BR Raju From nobody Fri Feb 13 14:48:20 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1C1A1A92 for ; Fri, 13 Feb 2015 14:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymYD7T22ovnF for ; Fri, 13 Feb 2015 14:48:08 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46F51A1B1D for ; Fri, 13 Feb 2015 14:48:07 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-6e-54de7f258ea2 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 4A.64.04231.52F7ED45; Fri, 13 Feb 2015 23:48:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 23:48:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAE5zxYAAB72MoACqnr0AAAx+3LA= Date: Fri, 13 Feb 2015 22:48:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D293A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54D98C0B.9040307@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D6C05D5@ESESSMB209.ericsson.se> <54DE3900.7030505@alum.mit.edu> In-Reply-To: <54DE3900.7030505@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja5q/b0Qgw/PrC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj540LbAXLeSv2vTnF3sB4nKuLkZNDQsBE 4uLkr+wQtpjEhXvr2UBsIYEjjBJntvF2MXIB2UsYJVa+6QEq4uBgE7CQ6P6nDVIjIuApsePj FGYQW1ggReL/392sEPFUiaVPTzNB2H4S53f/AZvJIqAqcerdHbBdvAK+EocPHGaBmD+TSeL6 5qmMIPM5BXQkdjZlgNQwAt3z/dQasDnMAuISt57MZ4K4U0BiyZ7zzBC2qMTLx/9YIWwlibWH t7NA1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCUHNzyW3cH4+rXjocYBTgYlXh4N2TcDRFiTSwrrsw9xCjN waIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NZyMqIrLV9ryxPex01EFPM3sBz 1GZWHUtmeOWqGxyfbjBflfthy7jOtnSe1rH/yRvP7X/YtuuDolO17P6dy7aV3jWze7Dt/yk5 zl3zXkT4V/94wrd61fsyyytfzx+c/nwK0+3CRX92J9ukTPS7Ps+B69OXU2cEmgJ6Jj88e/TN L970VaqbJuUHKrEUZyQaajEXFScCALDSVR1zAgAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:48:14 -0000 Hi, >>>>>> 2. Section 3.2.1.1: Given that the general feeling is that UDP=20 >>>>>> will be more common than TCP do we want to make a recommendation=20 >>>>>> on what transport CLUE endpoint should support in order to maximise = interop? >>>>> I guess we could say that TCP SHOULD only be used if needed for ICE p= urpose. >>>>> >>>>> But, I'd like to make sure other are ok with such approach too. >>>> What about adding the following text: >>>> >>>> "CLUE entities SHOULD NOT use the transport the SCTPoDTLS association= used to realize >>>> the CLUE Data Channel over TCP (using the "TCP/DTLS/SCTP" proto value= ), unless >>>> the the Interactive Connectivity Establishment (ICE) mechanism [RFC52= 45] is used and >>>> the ICE procedures determines that TCP transport is required." >>> [CNG] I think there's one "the" too many in the first line. Should it r= ead "CLUE entities SHOULD NOT transport the SCTPoDTLS >>> association used = to realize..."? >> >> Correct. I'll fix that. > > It is corrected in -08. But after thinking about it further, I think shou= ld not restrict this usage=20 > to ICE. There may be other circumstances when it is known that UDP won't = work. So how about: > > CLUE entities SHOULD NOT transport the SCTPoDTLS association used to > realize the CLUE data channel over TCP (using the "TCP/DTLS/SCTP" > proto value), unless it is known that UDP/DTLS/SCTP will not work. > (For instance, when the the Interactive Connectivity Establishment > (ICE) mechanism [RFC5245] is used and the ICE procedures determine > that TCP transport is required.) Looks good. I'll fix it in version -09. Regards, Christer From nobody Fri Feb 13 14:54:32 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249C61A1BAF for ; Fri, 13 Feb 2015 14:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_3AcXyIX_kD for ; Fri, 13 Feb 2015 14:54:23 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 60F9E1A1B84 for ; Fri, 13 Feb 2015 14:54:15 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi2so15072509wib.1 for ; Fri, 13 Feb 2015 14:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OmHqPPbwrE7ULqkn+mamL6HgryvEX4zEMghAiUlGThg=; b=XQAudEKQEaJS0YTQUohoZE3yRkyMyT0QW9fcD3hxgVcd9NmUO5c0VhIToDF/oewLrF w05GQfcjbmrVmKR4tawpxQD3T6Jz0l6MCx2Yr3vRQRLMyxo5phAalYBc73NFWJZI5g5z Ac6pDAZiZnsQGVihRHkytEabUtH8tp0+UPbmMAdjRdypG5m3CdYRANhy0o0YQuyoXuyc sKpUR77R9ZT0mgdd3uBjrt1s06nCfFAjIMBgpXPdORdTQwIZdSlLzwnl68I2aZ2wJGlg zj4JQLWZ7Lb1Gfk1R4Q+WbddxFq3NuqOzpIILAprRWMhEaAKscCfpXHof6iDm6cHpcLW rezw== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr23812876wjp.20.1423868053924; Fri, 13 Feb 2015 14:54:13 -0800 (PST) Received: by 10.194.120.167 with HTTP; Fri, 13 Feb 2015 14:54:13 -0800 (PST) Date: Fri, 13 Feb 2015 17:54:13 -0500 Message-ID: From: Daniel Burnett To: "clue@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d57368fb218050f001d9c Archived-At: Subject: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:54:27 -0000 --047d7b5d57368fb218050f001d9c Content-Type: text/plain; charset=UTF-8 Christer, Many of the comments I had for the -07 draft have already been addressed in -08, so thank you! General comments: - For novice (IESG) readers, if 'SCTPoDTLS' means something different than 'SCTP over DTLS', you should add that explanation in section 2 where you define 'SCTPoDTLS'. Otherwise, use the same term everywhere. - I will do a complete grammar/editorial review later, but for now I noticed that use of a/an before SCTP is inconsistent. Technically if you read it as 'S C T P' you should use 'an', but if you read it as 'Stream Control Transmission Protocol' you should use 'a'. It doesn't really matter which you use, but you should be consistent. - Similarly, capitalization of Data Channel, e.g., in 'WebRTC Data Channel', is inconsistent. Pick one style and use it everywhere. Section 1. Do we really want to confuse people with the text ' NOTE: The usage of the Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel is outside the scope of this document. ' in the document since we essentially require use of sdpneg? Or do we actually permit other ways to set up CLUE data channels? If we do permit other ways, this text should probably be made more generic in explaining that we define only one way to establish CLUE data channels, do not forbid other ways, but any other way (such as DCEP) is out of scope. Section 2. 'CLUE session refers to a SIP session [RFC3261] between to SIP UAs' -> 'CLUE session refers to a SIP session [RFC3261] between two SIP UAs' 'SCTP identifier is defined in [RFC4960] as a unsigned integer' -> 'SCTP identifier is defined in [RFC4960] as an unsigned integer' Section 3. I don't know whether it belongs here or in section 1, but it might help a novice reader to say a little more about the relationship between WebRTC data channels and CLUE data channels as context. Just a few sentences might help. For example, the first paragraph in 3.1 could be changed to 'This section describes the realization of a CLUE data channel using a WebRTC data channel. The WebRTC Data Channel was developed to provide a simple mechanism for two endpoints, for example two web browsers, to establish channels for carrying arbitrary data. The WebRTC Data Channel accomplishes this by creating SCTP streams over a DTLS connection. The details are described in [I-D.ietf-rtcweb-data-channel]. Additional items need to be defined in order to use a WebRTC data channel as a CLUE data channel: a set of SCTP characteristics specific to a CLUE data channel, the values of the m- line describing the SCTPoDTLS association associated with the WEBRTC Data Channel, and the usage of the SDP-based "SCTP over DTLS" data channel negotiation mechanism for creating the CLUE data channel.' You could also consider adding a few words about how a WebRTC data channel is normally expected to be signaled so readers can understand what is different about what CLUE is defining. -- dan --047d7b5d57368fb218050f001d9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer,

Many of the comments I had for the -= 07 draft have already been addressed in -08, so thank you!

General c= omments:
- For novice (IESG) readers, if 'SCTPoDTLS' means somet= hing different than 'SCTP over DTLS', you should add that explanati= on in section 2 where you define 'SCTPoDTLS'.=C2=A0 Otherwise, use = the same term everywhere.
- I will do a complete grammar/editorial revie= w later, but for now I noticed that use of a/an before SCTP is inconsistent= .=C2=A0 Technically if you read it as 'S C T P' you should use '= ;an', but if you read it as 'Stream Control Transmission Protocol&#= 39; you should use 'a'.=C2=A0 It doesn't really matter which yo= u use, but you should be consistent.
- Similarly, capitalization of Data= Channel, e.g., in 'WebRTC Data Channel', is inconsistent.=C2=A0 Pi= ck one style and use it everywhere.


Section 1.

Do we real= ly want to confuse people with the text
'=C2=A0 NOTE: The usage of = the Data Channel Establishment Protocol (DCEP)
=C2=A0=C2=A0 [I-D.ietf-rt= cweb-data-protocol] for establishing a CLUE data channel
=C2=A0=C2=A0 is= outside the scope of this document. '
in the document since we esse= ntially require use of sdpneg?=C2=A0 Or do we actually permit other ways to= set up CLUE data channels?=C2=A0 If we do permit other ways, this text sho= uld probably be made more generic in explaining that we define only one way= to establish CLUE data channels, do not forbid other ways, but any other w= ay (such as DCEP) is out of scope.


Section 2.

'CLUE s= ession refers to a SIP session [RFC3261] between to SIP UAs' ->
&= #39;CLUE session refers to a SIP session [RFC3261] between two SIP UAs'=

'SCTP identifier is defined in [RFC4960] as a unsigned integer&= #39; ->
'SCTP identifier is defined in [RFC4960] as an unsigned i= nteger'


Section 3.

I don't know whether it belong= s here or in section 1, but it might help a novice reader to say a little m= ore about the relationship between WebRTC data channels and CLUE data chann= els as context.=C2=A0 Just a few sentences might help.=C2=A0 For example, t= he first paragraph in 3.1 could be changed to

'This section desc= ribes the realization of a CLUE data channel using a WebRTC data channel.= =C2=A0 The WebRTC Data Channel was developed to provide a simple mechanism = for two endpoints, for example two web browsers, to establish channels for = carrying arbitrary data.=C2=A0 The WebRTC Data Channel accomplishes this by= creating SCTP streams over a DTLS connection.=C2=A0 The details are descri= bed in [I-D.ietf-rtcweb-data-channel].=C2=A0 Additional items need to be de= fined in order to use a WebRTC data channel as a CLUE data channel:=C2=A0 a= set of SCTP characteristics specific to a CLUE data channel, the values of= the m- line describing the SCTPoDTLS association associated with the WEBRT= C Data Channel, and the usage of the SDP-based "SCTP over DTLS" d= ata channel negotiation mechanism for creating the CLUE data channel.'<= br>
You could also consider adding a few words about how a WebRTC data c= hannel is normally expected to be signaled so readers can understand what i= s different about what CLUE is defining.

-- dan

--047d7b5d57368fb218050f001d9c-- From nobody Fri Feb 13 14:56:29 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8191A008A for ; Fri, 13 Feb 2015 14:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, 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 ZRIAZPIDip6J for ; Fri, 13 Feb 2015 14:56:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D1A1A0039 for ; Fri, 13 Feb 2015 14:56:21 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-25-54de8113e113 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 79.15.04231.3118ED45; Fri, 13 Feb 2015 23:56:19 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Fri, 13 Feb 2015 23:56:19 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments Thread-Index: AdBB/zQ6iH1sKyJ6RnGlaxePNrwv1ABqnuLgAHUKDIAAEslKEAB5XImAAAwvaEA= Date: Fri, 13 Feb 2015 22:56:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D295F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D695730@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D6AEDC2@ESESSMB209.ericsson.se> <54DA8EFF.8090302@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D6CAADC@ESESSMB209.ericsson.se> <54DE3B83.9040305@alum.mit.edu> In-Reply-To: <54DE3B83.9040305@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja5w470Qg7vLjC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuja+Z0xoL7nBVLuy+xNjCeYe9i5OSQEDCR ONa8nwnCFpO4cG89WxcjF4eQwBFGiT99bcwQzhJGiZNXGxm7GDk42AQsJLr/aYM0iAh4Suz4 OIUZxBYWSJH4/3c3K0Q8VWLp09NMELafxOInvxlBbBYBVYld63pZQGxeAV+Jv48us0LMn8kk 8XVmL1gzp4COxMlTe8GGMgJd9P3UGrBBzALiEreezIe6VEBiyZ7zzBC2qMTLx/9YIWwlibWH t7NA1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCkHNzyW3cH4+rXjocYBTgYlXh4N2TcDRFiTSwrrsw9xCjN waIkzmtnfChESCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OUldnn9ZNLlqd5FLrU3XjPdulR 0F6FriS/D3cOnbSP4RYrrz9udWzHRPng8+5/wv3KtUPiX5dNlJq3cM5vyTC+aVuZ/09JPf1b UFCY7W/iZpa+TtapRbMyP1hw2f5qVWsy2z7F9WiP58q9t3u0mb+58Xj3XDB/1Bs5x3Z1rIvc WxtNFoN3s5VYijMSDbWYi4oTAf6kuH11AgAA Archived-At: Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Christian's comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 22:56:26 -0000 Hi, >>>> What about adding the following text: >>>> >>>> "NOTE: As CLUE entities are required to use ordered SCTP message deli= very, >>>> with full reliability, according to the procedures in [I-D.ietf-mmusi= c-data-channel-sdpneg] >>>> the ordered, max-retr and max-time attribute parameters are not us= ed when >>>> negotiating CLUE data channels." >>> >>> This is good, except that we should not exclude the possibility of expl= icitly specifying=20 >>> reliable ordered delivery, by including 'ordered' >>> with the appropriate value. (I can't tell whether that is "0" or "1". >>> Right how the text defines them both as meaning ordered.) >> >> Correct. > > I'm ok with table 2 now. But I think it would be good for the example in= =20 > 3.3.4 (table 1) to show the use of the ordered attribute: > > m=3Dapplication 54111 UDP/DTLS/SCTP webrtc-datachannel > a=3Dsctp-port: 5000 > a=3Ddcmap:2 subprotocol=3D"CLUE";ordered=3Dtrue > > That doesn't depend on the default value for ordered. I'll add the ordered parameter with a true value (I assume it will be defin= ed as a token, and not a quoted string) to the example in version -09. Thanks! Regards, Christer From nobody Fri Feb 13 15:19:52 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECA71A0367 for ; Fri, 13 Feb 2015 15:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 YSSaUZ0kBxKO for ; Fri, 13 Feb 2015 15:19:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0291A008A for ; Fri, 13 Feb 2015 15:19:48 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-e6-54de86925f9c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FA.6A.04076.2968ED45; Sat, 14 Feb 2015 00:19:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.248]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0210.002; Sat, 14 Feb 2015 00:19:45 +0100 From: Christer Holmberg To: Daniel Burnett , "clue@ietf.org" Thread-Topic: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments Thread-Index: AQHQR+ASuFqrpnaF1ESNMsuue/C/BJzvMdwQ Date: Fri, 13 Feb 2015 23:19:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje6ktnshBpNPC1vsP3WZ2WLjTm0H Jo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK2POrQnMBa80K1Yd3M/cwPhAo4uRk0NCwETi 8MtbjBC2mMSFe+vZQGwhgSOMEksWmnQxcgHZSxglVpw+zNTFyMHBJmAh0f1PG6RGRMBP4vS0 A+wgtrBAmMTJM01sEPFwie99z5ghbCOJ3+dngcVZBFQl9h77DmbzCvhKHFt0ix1iV4BE2+JG sDinQKDEi7/rWEBsRqB7vp9awwRiMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwlSTWHt7O AnIms4CmxPpd+hCtihJTuh+yQ6wVlDg58wnLBEbRWUimzkLomIWkYxaSjgWMLKsYRYtTi4tz 042M9FKLMpOLi/Pz9PJSSzYxAuPj4JbfVjsYDz53PMQowMGoxMO7IeNuiBBrYllxZe4hRmkO FiVxXjvjQyFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPUlz9WbzlTaGx+5tyxD/Zh5ov/q ApZaTs0v9xrvfU1cvOexsuUVhbsOZ3Sc2FisE2d/c3LvFgmfk7Dmj+zeBPvNIS474x77T33m rayktWvexL+Fgsl2yUsPzPjQWzfdM/Y4Byf/DzGRPzwnUpdtW/3zzgbO1xv4Jgrf03P9fPvc wkbmi0Hpi5RYijMSDbWYi4oTAc5kFuVwAgAA Archived-At: Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2015 23:19:51 -0000 SGkgRGFuLA0KDQpUaGFua3MgZm9yIHlvdXIgcmV2aWV3ISBTZWUgaW5saW5lLg0KDQpHZW5lcmFs IGNvbW1lbnRzOg0KDQo+IC0gRm9yIG5vdmljZSAoSUVTRykgcmVhZGVycywgaWYgJ1NDVFBvRFRM UycgbWVhbnMgc29tZXRoaW5nIGRpZmZlcmVudCB0aGFuICdTQ1RQIG92ZXIgDQo+IERUTFMnLCB5 b3Ugc2hvdWxkIGFkZCB0aGF0IGV4cGxhbmF0aW9uIGluIHNlY3Rpb24gMiB3aGVyZSB5b3UgZGVm aW5lICdTQ1RQb0RUTFMnLsKgIE90aGVyd2lzZSwgDQo+IHVzZSB0aGUgc2FtZSB0ZXJtIGV2ZXJ5 d2hlcmUuDQoNClNlY3Rpb24gMiBkb2VzIHNheToNCg0KCSJTQ1RQb0RUTFMgYXNzb2NpYXRpb24g cmVmZXJzIHRvIGFuIFNDVFAgYXNzb2NpYXRpb24gY2FycmllZCBvdmVyIGFuDQogICAJRFRMUyBj b25uZWN0aW9uIFtJLUQuaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzXS4iDQoNCkknbSBub3Qg c3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3Ugd2FudCBtZSB0byBhZGQ/DQoNCi0tLS0tLS0tLS0t LS0tLQ0KDQo+LSBJIHdpbGwgZG8gYSBjb21wbGV0ZSBncmFtbWFyL2VkaXRvcmlhbCByZXZpZXcg bGF0ZXIsIGJ1dCBmb3Igbm93IEkgbm90aWNlZCB0aGF0IHVzZSBvZiBhL2FuIGJlZm9yZSBTQ1RQ IGlzID5pbmNvbnNpc3RlbnQuwqAgVGVjaG5pY2FsbHkgaWYgeW91IHJlYWQgaXQgYXMgJ1MgQyBU IFAnIHlvdSBzaG91bGQgdXNlICdhbicsIGJ1dCBpZiB5b3UgcmVhZCBpdCBhcyAnU3RyZWFtIENv bnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sJyA+eW91IHNob3VsZCB1c2UgJ2EnLsKgIEl0IGRv ZXNuJ3QgcmVhbGx5IG1hdHRlciB3aGljaCB5b3UgdXNlLCBidXQgeW91IHNob3VsZCBiZSBjb25z aXN0ZW50Lg0KDQpNeSBpbnRlbnRpb24gaGFzIGJlZW4gdG8gdXNlICdhbicuIEknbGwgZml4IGl0 IGluIC0wOS4NCg0KPiAtIFNpbWlsYXJseSwgY2FwaXRhbGl6YXRpb24gb2YgRGF0YSBDaGFubmVs LCBlLmcuLCBpbiAnV2ViUlRDIERhdGEgQ2hhbm5lbCcsIGlzIGluY29uc2lzdGVudC7CoCBQaWNr IG9uZSBzdHlsZSBhbmQgdXNlIGl0IGV2ZXJ5d2hlcmUuDQoNCkknbGwgdXNlIHNtYWxsIGxldHRl cnMgZm9yIG5vdy4gT25jZSB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBkcmFmdCBpcyByZWFkeSwg SSdsbCBhbGlnbi4NCg0KLS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24gMS4NCg0KPiBEbyB3ZSBy ZWFsbHkgd2FudCB0byBjb25mdXNlIHBlb3BsZSB3aXRoIHRoZSB0ZXh0IA0KPiAnwqAgTk9URTog VGhlIHVzYWdlIG9mIHRoZSBEYXRhIENoYW5uZWwgRXN0YWJsaXNobWVudCBQcm90b2NvbCAoRENF UCkNCj7CoMKgIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0gZm9yIGVzdGFibGlzaGlu ZyBhIENMVUUgZGF0YSBjaGFubmVsDQo+wqDCoCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LiAnDQo+IGluIHRoZSBkb2N1bWVudCBzaW5jZSB3ZSBlc3NlbnRpYWxseSByZXF1 aXJlIHVzZSBvZiBzZHBuZWc/wqAgT3IgZG8gd2UgYWN0dWFsbHkgcGVybWl0IG90aGVyIHdheXMg dG8gc2V0IHVwIENMVUUgZGF0YSANCj4gY2hhbm5lbHM/wqAgSWYgd2UgZG8gcGVybWl0IG90aGVy IHdheXMsIHRoaXMgdGV4dCBzaG91bGQgcHJvYmFibHkgYmUgbWFkZSBtb3JlIGdlbmVyaWMgaW4g ZXhwbGFpbmluZyB0aGF0IHdlIGRlZmluZSBvbmx5IG9uZSANCj4gd2F5IHRvIGVzdGFibGlzaCBD TFVFIGRhdGEgY2hhbm5lbHMsIGRvIG5vdCBmb3JiaWQgb3RoZXIgd2F5cywgYnV0IGFueSBvdGhl ciB3YXkgKHN1Y2ggYXMgRENFUCkgaXMgb3V0IG9mIHNjb3BlLg0KDQpJIHRoaW5rIHRoZSBub3Rl IGlzIHVzZWZ1bCwgYmVjYXVzZSB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBkcmFmdCBkb2VzIG1l bnRpb24gRENFUCBhcyBhIG1lY2hhbmlzbSBmb3IgZXN0YWJsaXNoaW5nIGRhdGEgY2hhbm5lbHMu IEFuZCwgaW4gbXkgb3BpbmlvbiAib3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCIg ZG9lcyBtZWFuIHRoYXQgb3RoZXJzIGNhbiBkZWZpbmUgaXQgOikNCg0KLS0tLS0tLS0tLS0tLS0t DQoNClNlY3Rpb24gMi4NCg0KPidDTFVFIHNlc3Npb24gcmVmZXJzIHRvIGEgU0lQIHNlc3Npb24g W1JGQzMyNjFdIGJldHdlZW4gdG8gU0lQIFVBcycgLT4NCj4nQ0xVRSBzZXNzaW9uIHJlZmVycyB0 byBhIFNJUCBzZXNzaW9uIFtSRkMzMjYxXSBiZXR3ZWVuIHR3byBTSVAgVUFzJw0KDQpXaWxsIGJl IGZpeGVkIGluIC0wOS4NCg0KPidTQ1RQIGlkZW50aWZpZXIgaXMgZGVmaW5lZCBpbiBbUkZDNDk2 MF0gYXMgYSB1bnNpZ25lZCBpbnRlZ2VyJyAtPg0KPidTQ1RQIGlkZW50aWZpZXIgaXMgZGVmaW5l ZCBpbiBbUkZDNDk2MF0gYXMgYW4gdW5zaWduZWQgaW50ZWdlcicNCg0KV2lsbCBiZSBmaXhlZCBp biAtMDkuDQoNCi0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN0aW9uIDMuDQoNCj4gSSBkb24ndCBrbm93 IHdoZXRoZXIgaXQgYmVsb25ncyBoZXJlIG9yIGluIHNlY3Rpb24gMSwgYnV0IGl0IG1pZ2h0IGhl bHAgYSBub3ZpY2UgcmVhZGVyIHRvIHNheSBhIGxpdHRsZSBtb3JlIGFib3V0IHRoZSByZWxhdGlv bnNoaXAgPiBiZXR3ZWVuIFdlYlJUQyBkYXRhIGNoYW5uZWxzIGFuZCBDTFVFIGRhdGEgY2hhbm5l bHMgYXMgY29udGV4dC7CoCBKdXN0IGEgZmV3IHNlbnRlbmNlcyBtaWdodCBoZWxwLsKgIEZvciBl eGFtcGxlLCB0aGUgZmlyc3QgDQo+IHBhcmFncmFwaCBpbiAzLjEgY291bGQgYmUgY2hhbmdlZCB0 bw0KPg0KPiAnVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcmVhbGl6YXRpb24gb2YgYSBDTFVF IGRhdGEgY2hhbm5lbCB1c2luZyBhIFdlYlJUQyBkYXRhIGNoYW5uZWwuwqAgVGhlIFdlYlJUQyBE YXRhIENoYW5uZWwgd2FzIA0KPiBkZXZlbG9wZWQgdG8gcHJvdmlkZSBhIHNpbXBsZSBtZWNoYW5p c20gZm9yIHR3byBlbmRwb2ludHMsIGZvciBleGFtcGxlIHR3byB3ZWIgYnJvd3NlcnMsIHRvIGVz dGFibGlzaCBjaGFubmVscyBmb3IgY2FycnlpbmcgDQo+IGFyYml0cmFyeSBkYXRhLsKgIFRoZSBX ZWJSVEMgRGF0YSBDaGFubmVsIGFjY29tcGxpc2hlcyB0aGlzIGJ5IGNyZWF0aW5nIFNDVFAgc3Ry ZWFtcyBvdmVyIGEgRFRMUyBjb25uZWN0aW9uLsKgIFRoZSBkZXRhaWxzIGFyZSANCj4gZGVzY3Jp YmVkIGluIFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXS7CoCBBZGRpdGlvbmFsIGl0ZW1z IG5lZWQgdG8gYmUgZGVmaW5lZCBpbiBvcmRlciB0byB1c2UgYSBXZWJSVEMgZGF0YSBjaGFubmVs IGFzIGEgDQo+IENMVUUgZGF0YSBjaGFubmVsOsKgIGEgc2V0IG9mIFNDVFAgY2hhcmFjdGVyaXN0 aWNzIHNwZWNpZmljIHRvIGEgQ0xVRSBkYXRhIGNoYW5uZWwsIHRoZSB2YWx1ZXMgb2YgdGhlIG0t IGxpbmUgZGVzY3JpYmluZyB0aGUgDQo+IFNDVFBvRFRMUyBhc3NvY2lhdGlvbiBhc3NvY2lhdGVk IHdpdGggdGhlIFdFQlJUQyBEYXRhIENoYW5uZWwsIGFuZCB0aGUgdXNhZ2Ugb2YgdGhlIFNEUC1i YXNlZCAiU0NUUCBvdmVyIERUTFMiIGRhdGEgDQo+IGNoYW5uZWwgbmVnb3RpYXRpb24gbWVjaGFu aXNtIGZvciBjcmVhdGluZyB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwuJw0KDQpJIGNhbiBkbyB0aGUg bW9kaWZpY2F0aW9uIGluIC0wOS4NCg0KPiBZb3UgY291bGQgYWxzbyBjb25zaWRlciBhZGRpbmcg YSBmZXcgd29yZHMgYWJvdXQgaG93IGEgV2ViUlRDIGRhdGEgY2hhbm5lbCBpcyBub3JtYWxseSAN Cj4gZXhwZWN0ZWQgdG8gYmUgc2lnbmFsZWQgc28gcmVhZGVycyBjYW4gdW5kZXJzdGFuZCB3aGF0 IGlzIGRpZmZlcmVudCBhYm91dCB3aGF0IENMVUUgaXMgZGVmaW5pbmcuDQoNClBlcmhhcHMgSSBj b3VsZCBtb3ZlIHRoZSBub3RlIHlvdSBjb21tZW50ZWQgb24gZWFybGllciBkb3duIHRvIHNlY3Rp b24gMy4xPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From nobody Mon Feb 16 04:39:39 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA171A1AE8 for ; Mon, 16 Feb 2015 04:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5-ZdyrDcNiD for ; Mon, 16 Feb 2015 04:39:35 -0800 (PST) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3D21A1A6F for ; Mon, 16 Feb 2015 04:39:35 -0800 (PST) Received: from 212-147-18-59.fix.access.vtx.ch ([212.147.18.59]:46843 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YNKwJ-0002xS-Um; Mon, 16 Feb 2015 23:38:17 +1100 Message-ID: <54E1E4FD.2060505@nteczone.com> Date: Mon, 16 Feb 2015 23:39:25 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <01d601d036ed$d501abf0$7f0503d0$@gmail.com> <54D2C46E.1040700@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2A4C256@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 12:39:38 -0000 Hello Mark, Please see my replies below. Regards, Christian ..snip.. 1. Section 1 Introduction: I think it would be good to add a sentence to indicate that CLUE can be used in any multistream environment. It's not just related to telepresence. > [Duckworth, Mark] How about adding "This includes cases using multiple media streams that are not necessarily telepresence." [CNG] OK for me. > >> 2. Section 4 1st para: "This section provides an overview of the >> functional elements defined in this document to represent a telepresence >> system". Like the above comment perhaps we could replace telepresence >> with multistream? The section talks about different types of systems, >> telepresence, webcam, multicast etc. CLUE can be applied to all of them. > [Duckworth, Mark] How about "telepresence or multistream"? The spatial size stuff can be useful for telepresence even without multistream. [CNG] OK > >> 3. Section 5 pg14 2nd para: "The Consumer in the Endpoint receives the >> information provided by the Provider, and can use it for two >> purposes" The paragraph only talks about using the information for >> constructing a Configure and for SDP. The provider can also use the >> information for rendering decisions. It would be good to clarify this. > [Duckworth, Mark] I think you mean the consumer can use the information for rendering? How about saying "... can use it for three purposes" and then add a sentence about rendering? [CNG] OK > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are >> optional in the consumer and that it is free to ignore the information. >> Whilst its true for the Advertisement I don't think this is generally >> true. It shouldn't ignore the Options message. > [Duckworth, Mark] I think it's okay the way it is. The protocol document has the details. [CNG] Then why don't we remove the sentence and really leave it up to the protocol document? I think we're really only talking about the Advertisement and even for that is it true. i.e. the Consumer shouldn't ignore the "allow subset choice" parameter. > >> 5. Section 7.1.1.3 3rd para: "If the Area of Capture is not specified, >> it means that whilst the Video Capture is not spatially related to any >> other Video Capture". Is this true? Captures in the one scene ARE >> spatially related. If the Area of capture is not included isn't the >> Provider just saying that it can't provide specific details on the relation? > [Duckworth, Mark] How about "If the Area of Capture is not specified, it means the Video Capture is spatially related to other Captures in the same Scene, but there is no detailed information on the relationship." [CNG] OK. > >> 6. Section 7.1.1.13: "This attribute is only applicable to video >> Captures and presentation streams with visual information." Could this >> also be applicable to audio captures? i.e. lyrics along with audio. > [Duckworth, Mark] I don't remember why that restriction was added. Was that in your original proposal for this attribute? It is okay with me to remove this sentence. [CNG] Yes it was the original based on a comment I received. In hindsight I don't think I should have proposed it. > ..snip.. From nobody Thu Feb 19 09:31:06 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92321A039C for ; Thu, 19 Feb 2015 09:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 ba9_eIdWc_xh for ; Thu, 19 Feb 2015 09:31:03 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05E21A001C for ; Thu, 19 Feb 2015 09:31:02 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-9d-54e61dd4e04f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A5.FD.04076.4DD16E45; Thu, 19 Feb 2015 18:31:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Thu, 19 Feb 2015 18:29:54 +0100 From: Christer Holmberg To: Christer Holmberg , Daniel Burnett , "clue@ietf.org" Thread-Topic: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments Thread-Index: AQHQR+OVbK2kyPdsUEOggVHLuVK2NZz4Q4Rg Date: Thu, 19 Feb 2015 17:29:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D70A5B9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvje4V2WchBvdPmFnsP3WZ2WLjTm0H Jo+ds+6yeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+PR75tsBbf0Ki6dbmBuYDyg28XIySEhYCJx c3s/G4QtJnHh3nogm4tDSOAIo8Tjs6/YIZwljBLT36xj7mLk4GATsJDo/qcNEhcRaGGUmLT2 FVi3sECYRMu7l+wgtohAuMSvldvZIGwjiY2zNjCD2CwCqhI/d/0Am8Mr4Csx40k+SFhIYArQ /J0RIDangJ/E1pMNYOWMQAd9P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmErSazY fokRZDyzgKbE+l36EK2KElO6H4JdxisgKHFy5hOWCYyis5BMnYXQMQtJxywkHQsYWVYxihan FhfnphsZ6aUWZSYXF+fn6eWllmxiBEbIwS2/rXYwHnzueIhRgINRiYf3Q+fTECHWxLLiytxD jNIcLErivHbGh0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MEb/jfqwTkLukz8zY/hTCb2O /ac/Gm9U/iQz/YLc/MvXphlEuM+r3PMobE+vxYYsc631LMHC+RXzpvjNb4i4tmdn137zzaw5 /hffdb07sfC3p9HLktVOD9YeZecMmGxabP9N7NG60n9vXuv5tj391rF8stFx3z/X1vm0b2hN tfzJ7Go46RWTeroSS3FGoqEWc1FxIgDh4fywcQIAAA== Archived-At: Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 17:31:05 -0000 SGkgRGFuLA0KDQpEaWQgeW91IHJlcGx5IHRvIHRoaXM/DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjbHVlIFttYWlsdG86Y2x1ZS1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDE0 IEZlYnJ1YXJ5IDIwMTUgMDE6MjANClRvOiBEYW5pZWwgQnVybmV0dDsgY2x1ZUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtjbHVlXSBkcmFmdC1jbHVlLWRhdGEtY2hhbm5lbC0wNyhubywgLTA4KSBX R0xDIHJldmlldyAtLSBEYW5CIGNvbW1lbnRzDQoNCkhpIERhbiwNCg0KVGhhbmtzIGZvciB5b3Vy IHJldmlldyEgU2VlIGlubGluZS4NCg0KR2VuZXJhbCBjb21tZW50czoNCg0KPiAtIEZvciBub3Zp Y2UgKElFU0cpIHJlYWRlcnMsIGlmICdTQ1RQb0RUTFMnIG1lYW5zIHNvbWV0aGluZyBkaWZmZXJl bnQgDQo+IHRoYW4gJ1NDVFAgb3ZlciBEVExTJywgeW91IHNob3VsZCBhZGQgdGhhdCBleHBsYW5h dGlvbiBpbiBzZWN0aW9uIDIgDQo+IHdoZXJlIHlvdSBkZWZpbmUgJ1NDVFBvRFRMUycuwqAgT3Ro ZXJ3aXNlLCB1c2UgdGhlIHNhbWUgdGVybSBldmVyeXdoZXJlLg0KDQpTZWN0aW9uIDIgZG9lcyBz YXk6DQoNCgkiU0NUUG9EVExTIGFzc29jaWF0aW9uIHJlZmVycyB0byBhbiBTQ1RQIGFzc29jaWF0 aW9uIGNhcnJpZWQgb3ZlciBhbg0KICAgCURUTFMgY29ubmVjdGlvbiBbSS1ELmlldGYtdHN2d2ct c2N0cC1kdGxzLWVuY2Fwc10uIg0KDQpJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91 IHdhbnQgbWUgdG8gYWRkPw0KDQotLS0tLS0tLS0tLS0tLS0NCg0KPi0gSSB3aWxsIGRvIGEgY29t cGxldGUgZ3JhbW1hci9lZGl0b3JpYWwgcmV2aWV3IGxhdGVyLCBidXQgZm9yIG5vdyBJIG5vdGlj ZWQgdGhhdCB1c2Ugb2YgYS9hbiBiZWZvcmUgU0NUUCBpcyA+aW5jb25zaXN0ZW50LsKgIFRlY2hu aWNhbGx5IGlmIHlvdSByZWFkIGl0IGFzICdTIEMgVCBQJyB5b3Ugc2hvdWxkIHVzZSAnYW4nLCBi dXQgaWYgeW91IHJlYWQgaXQgYXMgJ1N0cmVhbSBDb250cm9sIFRyYW5zbWlzc2lvbiBQcm90b2Nv bCcgPnlvdSBzaG91bGQgdXNlICdhJy7CoCBJdCBkb2Vzbid0IHJlYWxseSBtYXR0ZXIgd2hpY2gg eW91IHVzZSwgYnV0IHlvdSBzaG91bGQgYmUgY29uc2lzdGVudC4NCg0KTXkgaW50ZW50aW9uIGhh cyBiZWVuIHRvIHVzZSAnYW4nLiBJJ2xsIGZpeCBpdCBpbiAtMDkuDQoNCj4gLSBTaW1pbGFybHks IGNhcGl0YWxpemF0aW9uIG9mIERhdGEgQ2hhbm5lbCwgZS5nLiwgaW4gJ1dlYlJUQyBEYXRhIENo YW5uZWwnLCBpcyBpbmNvbnNpc3RlbnQuwqAgUGljayBvbmUgc3R5bGUgYW5kIHVzZSBpdCBldmVy eXdoZXJlLg0KDQpJJ2xsIHVzZSBzbWFsbCBsZXR0ZXJzIGZvciBub3cuIE9uY2UgdGhlIFdlYlJU QyBkYXRhIGNoYW5uZWwgZHJhZnQgaXMgcmVhZHksIEknbGwgYWxpZ24uDQoNCi0tLS0tLS0tLS0t LS0tLQ0KDQpTZWN0aW9uIDEuDQoNCj4gRG8gd2UgcmVhbGx5IHdhbnQgdG8gY29uZnVzZSBwZW9w bGUgd2l0aCB0aGUgdGV4dCAgJ8KgIE5PVEU6IFRoZSB1c2FnZSANCj5vZiB0aGUgRGF0YSBDaGFu bmVsIEVzdGFibGlzaG1lbnQgUHJvdG9jb2wgKERDRVApDQo+wqDCoCBbSS1ELmlldGYtcnRjd2Vi LWRhdGEtcHJvdG9jb2xdIGZvciBlc3RhYmxpc2hpbmcgYSBDTFVFIGRhdGEgY2hhbm5lbA0KPsKg wqAgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gJw0KPiBpbiB0aGUgZG9j dW1lbnQgc2luY2Ugd2UgZXNzZW50aWFsbHkgcmVxdWlyZSB1c2Ugb2Ygc2RwbmVnP8KgIE9yIGRv IHdlIA0KPmFjdHVhbGx5IHBlcm1pdCBvdGhlciB3YXlzIHRvIHNldCB1cCBDTFVFIGRhdGEgIGNo YW5uZWxzP8KgIElmIHdlIGRvIA0KPnBlcm1pdCBvdGhlciB3YXlzLCB0aGlzIHRleHQgc2hvdWxk IHByb2JhYmx5IGJlIG1hZGUgbW9yZSBnZW5lcmljIGluIGV4cGxhaW5pbmcgdGhhdCB3ZSBkZWZp bmUgb25seSBvbmUgIHdheSB0byBlc3RhYmxpc2ggQ0xVRSBkYXRhIGNoYW5uZWxzLCBkbyBub3Qg Zm9yYmlkIG90aGVyIHdheXMsIGJ1dCBhbnkgb3RoZXIgd2F5IChzdWNoIGFzIERDRVApIGlzIG91 dCBvZiBzY29wZS4NCg0KSSB0aGluayB0aGUgbm90ZSBpcyB1c2VmdWwsIGJlY2F1c2UgdGhlIFdl YlJUQyBkYXRhIGNoYW5uZWwgZHJhZnQgZG9lcyBtZW50aW9uIERDRVAgYXMgYSBtZWNoYW5pc20g Zm9yIGVzdGFibGlzaGluZyBkYXRhIGNoYW5uZWxzLiBBbmQsIGluIG15IG9waW5pb24gIm91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQiIGRvZXMgbWVhbiB0aGF0IG90aGVycyBjYW4g ZGVmaW5lIGl0IDopDQoNCi0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN0aW9uIDIuDQoNCj4nQ0xVRSBz ZXNzaW9uIHJlZmVycyB0byBhIFNJUCBzZXNzaW9uIFtSRkMzMjYxXSBiZXR3ZWVuIHRvIFNJUCBV QXMnIC0+IA0KPidDTFVFIHNlc3Npb24gcmVmZXJzIHRvIGEgU0lQIHNlc3Npb24gW1JGQzMyNjFd IGJldHdlZW4gdHdvIFNJUCBVQXMnDQoNCldpbGwgYmUgZml4ZWQgaW4gLTA5Lg0KDQo+J1NDVFAg aWRlbnRpZmllciBpcyBkZWZpbmVkIGluIFtSRkM0OTYwXSBhcyBhIHVuc2lnbmVkIGludGVnZXIn IC0+IA0KPidTQ1RQIGlkZW50aWZpZXIgaXMgZGVmaW5lZCBpbiBbUkZDNDk2MF0gYXMgYW4gdW5z aWduZWQgaW50ZWdlcicNCg0KV2lsbCBiZSBmaXhlZCBpbiAtMDkuDQoNCi0tLS0tLS0tLS0tLS0t LQ0KDQpTZWN0aW9uIDMuDQoNCj4gSSBkb24ndCBrbm93IHdoZXRoZXIgaXQgYmVsb25ncyBoZXJl IG9yIGluIHNlY3Rpb24gMSwgYnV0IGl0IG1pZ2h0IA0KPiBoZWxwIGEgbm92aWNlIHJlYWRlciB0 byBzYXkgYSBsaXR0bGUgbW9yZSBhYm91dCB0aGUgcmVsYXRpb25zaGlwID4gDQo+IGJldHdlZW4g V2ViUlRDIGRhdGEgY2hhbm5lbHMgYW5kIENMVUUgZGF0YSBjaGFubmVscyBhcyBjb250ZXh0LsKg IEp1c3QgDQo+IGEgZmV3IHNlbnRlbmNlcyBtaWdodCBoZWxwLsKgIEZvciBleGFtcGxlLCB0aGUg Zmlyc3QgcGFyYWdyYXBoIGluIDMuMSANCj4gY291bGQgYmUgY2hhbmdlZCB0bw0KPg0KPiAnVGhp cyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcmVhbGl6YXRpb24gb2YgYSBDTFVFIGRhdGEgY2hhbm5l bCB1c2luZyBhIA0KPiBXZWJSVEMgZGF0YSBjaGFubmVsLsKgIFRoZSBXZWJSVEMgRGF0YSBDaGFu bmVsIHdhcyBkZXZlbG9wZWQgdG8gcHJvdmlkZSANCj4gYSBzaW1wbGUgbWVjaGFuaXNtIGZvciB0 d28gZW5kcG9pbnRzLCBmb3IgZXhhbXBsZSB0d28gd2ViIGJyb3dzZXJzLCB0byANCj4gZXN0YWJs aXNoIGNoYW5uZWxzIGZvciBjYXJyeWluZyBhcmJpdHJhcnkgZGF0YS7CoCBUaGUgV2ViUlRDIERh dGEgDQo+IENoYW5uZWwgYWNjb21wbGlzaGVzIHRoaXMgYnkgY3JlYXRpbmcgU0NUUCBzdHJlYW1z IG92ZXIgYSBEVExTIA0KPiBjb25uZWN0aW9uLsKgIFRoZSBkZXRhaWxzIGFyZSBkZXNjcmliZWQg aW4gDQo+IFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsXS7CoCBBZGRpdGlvbmFsIGl0ZW1z IG5lZWQgdG8gYmUgZGVmaW5lZCBpbiBvcmRlciB0byB1c2UgYSBXZWJSVEMgZGF0YSBjaGFubmVs IGFzIGEgQ0xVRSBkYXRhIGNoYW5uZWw6wqAgYSBzZXQgb2YgU0NUUCBjaGFyYWN0ZXJpc3RpY3Mg c3BlY2lmaWMgdG8gYSBDTFVFIGRhdGEgY2hhbm5lbCwgdGhlIHZhbHVlcyBvZiB0aGUgbS0gbGlu ZSBkZXNjcmliaW5nIHRoZSBTQ1RQb0RUTFMgYXNzb2NpYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRo ZSBXRUJSVEMgRGF0YSBDaGFubmVsLCBhbmQgdGhlIHVzYWdlIG9mIHRoZSBTRFAtYmFzZWQgIlND VFAgb3ZlciBEVExTIiBkYXRhIGNoYW5uZWwgbmVnb3RpYXRpb24gbWVjaGFuaXNtIGZvciBjcmVh dGluZyB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwuJw0KDQpJIGNhbiBkbyB0aGUgbW9kaWZpY2F0aW9u IGluIC0wOS4NCg0KPiBZb3UgY291bGQgYWxzbyBjb25zaWRlciBhZGRpbmcgYSBmZXcgd29yZHMg YWJvdXQgaG93IGEgV2ViUlRDIGRhdGEgDQo+IGNoYW5uZWwgaXMgbm9ybWFsbHkgZXhwZWN0ZWQg dG8gYmUgc2lnbmFsZWQgc28gcmVhZGVycyBjYW4gdW5kZXJzdGFuZCB3aGF0IGlzIGRpZmZlcmVu dCBhYm91dCB3aGF0IENMVUUgaXMgZGVmaW5pbmcuDQoNClBlcmhhcHMgSSBjb3VsZCBtb3ZlIHRo ZSBub3RlIHlvdSBjb21tZW50ZWQgb24gZWFybGllciBkb3duIHRvIHNlY3Rpb24gMy4xPw0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From nobody Thu Feb 19 11:17:09 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A961A0023 for ; Thu, 19 Feb 2015 11:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 TWogK-lP8FNx for ; Thu, 19 Feb 2015 11:17:05 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (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 A42AB1A0039 for ; Thu, 19 Feb 2015 11:17:04 -0800 (PST) Received: by wesw62 with SMTP id w62so1592399wes.12 for ; Thu, 19 Feb 2015 11:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A8bR1oENlB/52wMVQdiXtFd6Iidr7cMDb/WDhwNlLho=; b=WDmwIQiLdAU+pVKbzIQsNP0XZGu6soejM0nwk0YBP/H69bNceF0U2jqUKtech0A2ur HQXCNVCVJJhVguMtbTCAiXmlIZsU/gSguNGOOWcJD+NjG7jsdVhukD8yY87GYGsBjAoh 7nFn+yoPxP/vLo51tzIeEkze2v+uVT9G5h2Ri8qNg5YT0Qq07jdK5kuBuTBB5fJlA1U8 cCNmiWmzHLUunOSb5hxeJ77pl3L2Us4OZbDA0WkSeVVGjD3wZ/wSrr5sLttJ12g2uydN qv408VPoxjwx8lQAq6QSMARw+dNTyF6Q7+xku80+TfBg6xf1evOW0zriPhRiL7g+flHk eveA== MIME-Version: 1.0 X-Received: by 10.195.12.71 with SMTP id eo7mr12219027wjd.3.1424373423409; Thu, 19 Feb 2015 11:17:03 -0800 (PST) Received: by 10.194.120.167 with HTTP; Thu, 19 Feb 2015 11:17:03 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> Date: Thu, 19 Feb 2015 14:17:03 -0500 Message-ID: From: Daniel Burnett To: Christer Holmberg Content-Type: multipart/alternative; boundary=047d7bb04ee4ee0fb5050f75c723 Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:17:08 -0000 --047d7bb04ee4ee0fb5050f75c723 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 13, 2015 at 6:19 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Dan, > > Thanks for your review! See inline. > > General comments: > > > - For novice (IESG) readers, if 'SCTPoDTLS' means something different > than 'SCTP over > > DTLS', you should add that explanation in section 2 where you define > 'SCTPoDTLS'. Otherwise, > > use the same term everywhere. > > Section 2 does say: > > "SCTPoDTLS association refers to an SCTP association carried over > an > DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]." > > I'm not sure I understand what you want me to add? > In multiple locations you use "SCTP over DTLS", in quotes, to talk about SCTP over DTLS. You do define 'SCTPoDTLS association'. I'm just saying that you should either use 'SCTPoDTLS' or "SCTP over DTLS" everywhere. In the case of the association it would then either be 'SCTPoDTLS association' or 'SCTP over DTLS association', whichever you had chosen. The fact that you use 'SCTPoDTLS' could make someone wonder if you don't mean "SCTP over DTLS" when you use it. > > --------------- > > >- I will do a complete grammar/editorial review later, but for now I > noticed that use of a/an before SCTP is >inconsistent. Technically if you > read it as 'S C T P' you should use 'an', but if you read it as 'Stream > Control Transmission Protocol' >you should use 'a'. It doesn't really > matter which you use, but you should be consistent. > > My intention has been to use 'an'. I'll fix it in -09. > > > - Similarly, capitalization of Data Channel, e.g., in 'WebRTC Data > Channel', is inconsistent. Pick one style and use it everywhere. > > I'll use small letters for now. Once the WebRTC data channel draft is > ready, I'll align. > > --------------- > > Section 1. > > > Do we really want to confuse people with the text > > ' NOTE: The usage of the Data Channel Establishment Protocol (DCEP) > > [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE data channel > > is outside the scope of this document. ' > > in the document since we essentially require use of sdpneg? Or do we > actually permit other ways to set up CLUE data > > channels? If we do permit other ways, this text should probably be made > more generic in explaining that we define only one > > way to establish CLUE data channels, do not forbid other ways, but any > other way (such as DCEP) is out of scope. > > I think the note is useful, because the WebRTC data channel draft does > mention DCEP as a mechanism for establishing data channels. And, in my > opinion "outside the scope of this document" does mean that others can > define it :) > How about this? Replace the text I quote above with ' NOTE: This specification defines only one way to establish data channels. The mechanism defined in this specification is different from the Data Channel Establishment Protocol [I-D.ietf-rtcweb-data-protocol] defined for WebRTC data channels. Definition and/or usage of any protocol for establishing CLUE data channels other than that defined in this specification is out of scope for this document.' > --------------- > > Section 2. > > >'CLUE session refers to a SIP session [RFC3261] between to SIP UAs' -> > >'CLUE session refers to a SIP session [RFC3261] between two SIP UAs' > > Will be fixed in -09. > > >'SCTP identifier is defined in [RFC4960] as a unsigned integer' -> > >'SCTP identifier is defined in [RFC4960] as an unsigned integer' > > Will be fixed in -09. > > --------------- > > Section 3. > > > I don't know whether it belongs here or in section 1, but it might help > a novice reader to say a little more about the relationship > between > WebRTC data channels and CLUE data channels as context. Just a few > sentences might help. For example, the first > > paragraph in 3.1 could be changed to > > > > 'This section describes the realization of a CLUE data channel using a > WebRTC data channel. The WebRTC Data Channel was > > developed to provide a simple mechanism for two endpoints, for example > two web browsers, to establish channels for carrying > > arbitrary data. The WebRTC Data Channel accomplishes this by creating > SCTP streams over a DTLS connection. The details are > > described in [I-D.ietf-rtcweb-data-channel]. Additional items need to > be defined in order to use a WebRTC data channel as a > > CLUE data channel: a set of SCTP characteristics specific to a CLUE > data channel, the values of the m- line describing the > > SCTPoDTLS association associated with the WEBRTC Data Channel, and the > usage of the SDP-based "SCTP over DTLS" data > > channel negotiation mechanism for creating the CLUE data channel.' > > I can do the modification in -09. > > > You could also consider adding a few words about how a WebRTC data > channel is normally > > expected to be signaled so readers can understand what is different > about what CLUE is defining. > > Perhaps I could move the note you commented on earlier down to section 3.1? > I have proposed text after my earlier comment that should take care of this. > > Regards, > > Christer > > --047d7bb04ee4ee0fb5050f75c723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 13, 2015 at 6:19 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:
Hi Dan,

Thanks for your review! See inline.

General comments:

> - For novice (IESG) readers, if 'SCTPoDTLS' means something di= fferent than 'SCTP over
> DTLS', you should add that explanation in section 2 where you defi= ne 'SCTPoDTLS'.=C2=A0 Otherwise,
> use the same term everywhere.

Section 2 does say:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "SCTPoDTLS association refers to an SCTP a= ssociation carried over an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encap= s]."

I'm not sure I understand what you want me to add?

In multiple locations you use "SCTP over DTLS", i= n quotes, to talk about SCTP over DTLS.=C2=A0 You do define 'SCTPoDTLS = association'.=C2=A0 I'm just saying that you should either use '= ;SCTPoDTLS' or "SCTP over DTLS" everywhere.=C2=A0 In the case= of the association it would then either be 'SCTPoDTLS association'= or 'SCTP over DTLS association', whichever you had chosen.=C2=A0 T= he fact that you use 'SCTPoDTLS' could make someone wonder if you d= on't mean "SCTP over DTLS" when you use it.=C2=A0
=C2=A0<= br>

---------------

>- I will do a complete grammar/editorial review later, but for now I no= ticed that use of a/an before SCTP is >inconsistent.=C2=A0 Technically i= f you read it as 'S C T P' you should use 'an', but if you = read it as 'Stream Control Transmission Protocol' >you should us= e 'a'.=C2=A0 It doesn't really matter which you use, but you sh= ould be consistent.

My intention has been to use 'an'. I'll fix it in -09.
> - Similarly, capitalization of Data Channel, e.g., in 'WebRTC Data= Channel', is inconsistent.=C2=A0 Pick one style and use it everywhere.=

I'll use small letters for now. Once the WebRTC data channel dra= ft is ready, I'll align.

---------------

Section 1.

> Do we really want to confuse people with the text
> '=C2=A0 NOTE: The usage of the Data Channel Establishment Protocol= (DCEP)
>=C2=A0=C2=A0 [I-D.ietf-rtcweb-data-protocol] for establishing a CLUE da= ta channel
>=C2=A0=C2=A0 is outside the scope of this document. '
> in the document since we essentially require use of sdpneg?=C2=A0 Or d= o we actually permit other ways to set up CLUE data
> channels?=C2=A0 If we do permit other ways, this text should probably = be made more generic in explaining that we define only one
> way to establish CLUE data channels, do not forbid other ways, but any= other way (such as DCEP) is out of scope.

I think the note is useful, because the WebRTC data channel draft do= es mention DCEP as a mechanism for establishing data channels. And, in my o= pinion "outside the scope of this document" does mean that others= can define it :)

How about this?=C2=A0= Replace the text I quote above with

'=C2=A0 NOTE:=C2= =A0 This specification defines only one way to establish data channels.=C2= =A0 The mechanism defined in this specification is different from the Data = Channel Establishment Protocol [I-D.ietf-rtcweb-data-protocol] defined for = WebRTC data channels. Definition and/or usage of any protocol for establish= ing CLUE data channels other than that defined in this specification is out= of scope for this document.'


---------------

Section 2.

>'CLUE session refers to a SIP session [RFC3261] between to SIP UAs&= #39; ->
>'CLUE session refers to a SIP session [RFC3261] between two SIP UAs= '

Will be fixed in -09.

>'SCTP identifier is defined in [RFC4960] as a unsigned integer'= ->
>'SCTP identifier is defined in [RFC4960] as an unsigned integer'= ;

Will be fixed in -09.

---------------

Section 3.

> I don't know whether it belongs here or in section 1, but it might= help a novice reader to say a little more about the relationship > betw= een WebRTC data channels and CLUE data channels as context.=C2=A0 Just a fe= w sentences might help.=C2=A0 For example, the first
> paragraph in 3.1 could be changed to
>
> 'This section describes the realization of a CLUE data channel usi= ng a WebRTC data channel.=C2=A0 The WebRTC Data Channel was
> developed to provide a simple mechanism for two endpoints, for example= two web browsers, to establish channels for carrying
> arbitrary data.=C2=A0 The WebRTC Data Channel accomplishes this by cre= ating SCTP streams over a DTLS connection.=C2=A0 The details are
> described in [I-D.ietf-rtcweb-data-channel].=C2=A0 Additional items ne= ed to be defined in order to use a WebRTC data channel as a
> CLUE data channel:=C2=A0 a set of SCTP characteristics specific to a C= LUE data channel, the values of the m- line describing the
> SCTPoDTLS association associated with the WEBRTC Data Channel, and the= usage of the SDP-based "SCTP over DTLS" data
> channel negotiation mechanism for creating the CLUE data channel.'=

I can do the modification in -09.

> You could also consider adding a few words about how a WebRTC data cha= nnel is normally
> expected to be signaled so readers can understand what is different ab= out what CLUE is defining.

Perhaps I could move the note you commented on earlier down to secti= on 3.1?

I have proposed text after my e= arlier comment that should take care of this.
=C2=A0

Regards,

Christer


--047d7bb04ee4ee0fb5050f75c723-- From nobody Thu Feb 19 15:41:28 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B976B1A1A4C for ; Thu, 19 Feb 2015 15:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 43-no_tpN4Vg for ; Thu, 19 Feb 2015 15:41:24 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.113]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2B01A1A4B for ; Thu, 19 Feb 2015 15:41:24 -0800 (PST) Received: from [216.82.254.19] by server-17.bemta-7.messagelabs.com id 34/00-02754-3A476E45; Thu, 19 Feb 2015 23:41:23 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-96.messagelabs.com!1424389281!14686800!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15874 invoked from network); 19 Feb 2015 23:41:21 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 19 Feb 2015 23:41:21 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Thu, 19 Feb 2015 15:41:18 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 19 Feb 2015 15:41:19 -0800 Thread-Topic: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments Thread-Index: AdBMnJMwIWahfUlETtS5G+gXkyHcDg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEEEB@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: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 23:41:26 -0000 A couple of Christian's items remain in discussion... > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Monday, February 16, 2015 7:39 AM > To: Duckworth, Mark; clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 >=20 > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms are > >> optional in the consumer and that it is free to ignore the information= . > >> Whilst its true for the Advertisement I don't think this is generally > >> true. It shouldn't ignore the Options message. > > [Duckworth, Mark] I think it's okay the way it is. The protocol docume= nt > has the details. > [CNG] Then why don't we remove the sentence and really leave it up to > the protocol document? I think we're really only talking about the > Advertisement and even for that is it true. i.e. the Consumer shouldn't > ignore the "allow subset choice" parameter. [Duckworth, Mark] The sentence we are talking about is: " All CLUE protocol mechanisms are OPTIONAL in the Consumer in the sense t= hat, while the Consumer MUST be able to receive (and, potentially, gracefully acknowledge) CLUE messages, it is free to ignore the information provided therein." [Duckworth, Mark] On second thought, I think it is good to remove this sentence. But I'm hoping to get more people to agree before I take it out. The signaling document says the Provider can't send media until it receives a Configure message. So I think it really isn't optional at all, and a Con= sumer must send a valid Configure message if it wants to receive media. > >> 6. Section 7.1.1.13: "This attribute is only applicable to video > >> Captures and presentation streams with visual information." Could this > >> also be applicable to audio captures? i.e. lyrics along with audio. > > [Duckworth, Mark] I don't remember why that restriction was added. Was > that in your original proposal for this attribute? It is okay with me to= remove > this sentence. > [CNG] Yes it was the original based on a comment I received. In > hindsight I don't think I should have proposed it. [Duckworth, Mark] We are talking about the "embedded text" attribute. Based on the description " a Capture provides embedded textual information. For example the video Capture MAY contain speech to text information composed with the video image," it still seems to me this applies only to v= ideo. I don't understand how embedded text could be added to an audio encoding in this sense, as I understood it to mean the text would just appear in the de= coded and rendered media without any additional processing. Does anybody else want to comment? From nobody Fri Feb 20 08:56:55 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7F1A1B37 for ; Fri, 20 Feb 2015 08:56:54 -0800 (PST) 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 7019lh-yK96R for ; Fri, 20 Feb 2015 08:56:52 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61361A3BA1 for ; Fri, 20 Feb 2015 08:56:18 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so14336247wgh.3 for ; Fri, 20 Feb 2015 08:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=6+lbbHMXls1l9AuA8HRejHyv2z3XhTr22Cc3lpOG+Hc=; b=0zH2U2gt7PZm170BputLPzH5bo7GRbzmAlm3c5gbw1CB8ztJLR89vkQaXaOUBBm9tb ZQk8SJq2NHf43r717ibxfveo95tHukR/15fpsStXDliBkxTF/pWWw1+ZcC9ijjIupOCT imgG24yeh4F0VyQpDjdwm0GRmUxm8lMNGTa59oADFwF3/Ln0atvVpHqYkWqPZ/dc/ztH D6Yt/VNUxCHY5vI9RvzsEYy8cRc3fnGdgGQeP1b4SGnt++iAdHRsbWN1HLUeVbI5Pqss iWd9t3FcLY4QCfyb5x5tPzaKbjmL5MRxduzhI4O6rAKhCO+k7X9019ixgkeX2LEPIw+g ZAtw== X-Received: by 10.180.35.33 with SMTP id e1mr25563972wij.49.1424451377396; Fri, 20 Feb 2015 08:56:17 -0800 (PST) Received: from RoniE (bzq-79-178-200-101.red.bezeqint.net. [79.178.200.101]) by mx.google.com with ESMTPSA id hm6sm42826982wjb.32.2015.02.20.08.56.14 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 20 Feb 2015 08:56:16 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Christian Groves'" , References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEEEB@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEEEB@CRPMBOXPRD08.polycom.com> Date: Fri, 20 Feb 2015 18:56:10 +0200 Message-ID: <01da01d04d2e$22b38890$681a99b0$@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: AQIsnBgtbNbH2J587NSpwewSMPADwJxBH3eA Content-Language: en-us Archived-At: Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 16:56:54 -0000 Hi, Inline Roni as individual > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: 20 February, 2015 1:41 AM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian > comments > > A couple of Christian's items remain in discussion... > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > Sent: Monday, February 16, 2015 7:39 AM > > To: Duckworth, Mark; clue@ietf.org > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 > > > > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms > > >> are optional in the consumer and that it is free to ignore the information. > > >> Whilst its true for the Advertisement I don't think this is > > >> generally true. It shouldn't ignore the Options message. > > > [Duckworth, Mark] I think it's okay the way it is. The protocol > > > document > > has the details. > > [CNG] Then why don't we remove the sentence and really leave it up to > > the protocol document? I think we're really only talking about the > > Advertisement and even for that is it true. i.e. the Consumer > > shouldn't ignore the "allow subset choice" parameter. > > [Duckworth, Mark] The sentence we are talking about is: > " All CLUE protocol mechanisms are OPTIONAL in the Consumer in the sense > that, > while the Consumer MUST be able to receive (and, potentially, > gracefully acknowledge) CLUE messages, it is free to ignore the > information provided therein." > [Duckworth, Mark] On second thought, I think it is good to remove this > sentence. But I'm hoping to get more people to agree before I take it out. > The signaling document says the Provider can't send media until it receives a > Configure message. So I think it really isn't optional at all, and a Consumer > must send a valid Configure message if it wants to receive media. [Roni Even] I am not sure what is discussed, the example " allow subset choice" given by Christian is sent by the provider and the consumer may ignore it and not ask for subsets. Having said that, reading the paragraph it talks about the renderer in the consumer and the consumer. I am not sure why we have the distinction since we are talking about the consumer and it looks to me like the last sentence in the paragraph is the same as the sentence before that talks about the renderer in the consumer. My reading is that the consumer MUST send at least advertisement acknowledge (as defined in the CLUE protocol) and may send a configure, this means the an advertisement may be ignore and not require a configure message. Roni > > > >> 6. Section 7.1.1.13: "This attribute is only applicable to video > > >> Captures and presentation streams with visual information." Could > > >> this also be applicable to audio captures? i.e. lyrics along with audio. > > > [Duckworth, Mark] I don't remember why that restriction was added. > > > Was > > that in your original proposal for this attribute? It is okay with me > > to remove this sentence. > > [CNG] Yes it was the original based on a comment I received. In > > hindsight I don't think I should have proposed it. > > [Duckworth, Mark] We are talking about the "embedded text" attribute. > Based on the description " a Capture provides embedded textual information. > For example the video Capture MAY contain speech to text information > composed with the video image," it still seems to me this applies only to video. > I don't understand how embedded text could be added to an audio encoding in > this sense, as I understood it to mean the text would just appear in the decoded > and rendered media without any additional processing. > Does anybody else want to comment? [Roni Even] Looking at previous discussion it said that if we will need something for audio it will be a new attribute. Anyhow I do not have any objection to remove the restriction. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Feb 20 15:04:39 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E1A1A0276 for ; Fri, 20 Feb 2015 15:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBG_vW0qZFkk for ; Fri, 20 Feb 2015 15:04:36 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CF61A0194 for ; Fri, 20 Feb 2015 15:04:36 -0800 (PST) Received: from [216.82.241.100] by server-8.bemta-8.messagelabs.com id CF/E7-03164-38DB7E45; Fri, 20 Feb 2015 23:04:35 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-220.messagelabs.com!1424473474!16282939!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32517 invoked from network); 20 Feb 2015 23:04:35 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-6.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 20 Feb 2015 23:04:35 -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, 20 Feb 2015 15:05:04 -0800 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Fri, 20 Feb 2015 15:05:03 -0800 From: "Duckworth, Mark" To: Roni Even , 'Christian Groves' , "Stephan Wenger (stewe@stewe.org)" Date: Fri, 20 Feb 2015 15:04:31 -0800 Thread-Topic: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments Thread-Index: AQIsnBgtbNbH2J587NSpwewSMPADwJxBH3eAgABqQVA= Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEFF6@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEEEB@CRPMBOXPRD08.polycom.com> <01da01d04d2e$22b38890$681a99b0$@gmail.com> In-Reply-To: <01da01d04d2e$22b38890$681a99b0$@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: Cc: "clue@ietf.org" Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2015 23:04:39 -0000 I plan to submit an updated framework draft around March 3. I'll be on vaca= tion until then. I have several minor updates done, based on latest feedbac= k from Christian and Paul.=20 I'm not sure about the first issue about protocol mechanisms being optional= . I've asked Stephan about it, as I think he wrote that part. I expect for the second issue below, I will remove the restriction (as both= Christian and Roni suggest) unless people start objecting. Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Friday, February 20, 2015 11:56 AM > To: Duckworth, Mark; 'Christian Groves'; clue@ietf.org > Subject: RE: [clue] short WGLC on draft-ietf-clue-framework-20 - Christia= n > comments >=20 > Hi, > Inline > Roni as individual >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > > Sent: 20 February, 2015 1:41 AM > > To: Christian Groves; clue@ietf.org > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christ= ian > > comments > > > > A couple of Christian's items remain in discussion... > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > > Sent: Monday, February 16, 2015 7:39 AM > > > To: Duckworth, Mark; clue@ietf.org > > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 > > > > > > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol mechanisms > > > >> are optional in the consumer and that it is free to ignore the > information. > > > >> Whilst its true for the Advertisement I don't think this is > > > >> generally true. It shouldn't ignore the Options message. > > > > [Duckworth, Mark] I think it's okay the way it is. The protocol > > > > document > > > has the details. > > > [CNG] Then why don't we remove the sentence and really leave it up to > > > the protocol document? I think we're really only talking about the > > > Advertisement and even for that is it true. i.e. the Consumer > > > shouldn't ignore the "allow subset choice" parameter. > > > > [Duckworth, Mark] The sentence we are talking about is: > > " All CLUE protocol mechanisms are OPTIONAL in the Consumer in the > sense > > that, > > while the Consumer MUST be able to receive (and, potentially, > > gracefully acknowledge) CLUE messages, it is free to ignore the > > information provided therein." > > [Duckworth, Mark] On second thought, I think it is good to remove this > > sentence. But I'm hoping to get more people to agree before I take it > out. > > The signaling document says the Provider can't send media until it > receives a > > Configure message. So I think it really isn't optional at all, and a > Consumer > > must send a valid Configure message if it wants to receive media. > [Roni Even] I am not sure what is discussed, the example " allow subset > choice" given by Christian is sent by the provider and the consumer may > ignore it and not ask for subsets. > Having said that, reading the paragraph it talks about the renderer in th= e > consumer and the consumer. I am not sure why we have the distinction sinc= e > we are talking about the consumer and it looks to me like the last senten= ce > in the paragraph is the same as the sentence before that talks about the > renderer in the consumer. > My reading is that the consumer MUST send at least advertisement > acknowledge (as defined in the CLUE protocol) and may send a configure, > this > means the an advertisement may be ignore and not require a configure > message. >=20 > Roni >=20 > > > > > >> 6. Section 7.1.1.13: "This attribute is only applicable to video > > > >> Captures and presentation streams with visual information." Could > > > >> this also be applicable to audio captures? i.e. lyrics along with > audio. > > > > [Duckworth, Mark] I don't remember why that restriction was added. > > > > Was > > > that in your original proposal for this attribute? It is okay with m= e > > > to remove this sentence. > > > [CNG] Yes it was the original based on a comment I received. In > > > hindsight I don't think I should have proposed it. > > > > [Duckworth, Mark] We are talking about the "embedded text" attribute. > > Based on the description " a Capture provides embedded textual > information. > > For example the video Capture MAY contain speech to text information > > composed with the video image," it still seems to me this applies only = to > video. > > I don't understand how embedded text could be added to an audio > encoding > in > > this sense, as I understood it to mean the text would just appear in th= e > decoded > > and rendered media without any additional processing. > > Does anybody else want to comment? > [Roni Even] Looking at previous discussion it said that if we will need > something for audio it will be a new attribute. Anyhow I do not have any > objection to remove the restriction. >=20 > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From nobody Sat Feb 21 05:11:33 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501DA1A19F6 for ; Sat, 21 Feb 2015 05:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 8lBcGPAg7Rij for ; Sat, 21 Feb 2015 05:11:29 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9C51A024E for ; Sat, 21 Feb 2015 05:11:28 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-21-54e883fdb787 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B6.86.04076.DF388E45; Sat, 21 Feb 2015 14:11:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0210.002; Sat, 21 Feb 2015 14:11:25 +0100 From: Christer Holmberg To: Daniel Burnett Thread-Topic: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments Thread-Index: AQHQR+OVbK2kyPdsUEOggVHLuVK2NZz4UL2AgALA7JA= Date: Sat, 21 Feb 2015 13:11:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D70EB27@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> 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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvje7f5hchBu03rCz2n7rMbLFxp7YD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTFt+XT2gi1WFTPmXmVuYPxi0cXIySEhYCJx 5WcLO4QtJnHh3nq2LkYuDiGBI4wSU59+YIJwljBKzD/+BSjDwcEmYCHR/U8bpEFEQFfi44u5 zCA2s4CyxNeGTUwgtrBAmETLu5fsEDXhEr9WbmeDsK0kPh5czQgyhkVAVWLvyQCQMK+Ar8Sz B7tZIVbdZpRY1ncQbCanQKDE/we3GUFsRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIWlXj5 +B8rhK0ksej2ZyaQXcwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYxWYhmToLoWMWko5ZSDoW MLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMnINbflvtYDz43PEQowAHoxIP74Yvz0OE WBPLiitzDzFKc7AoifPaGR8KERJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY/2jVm91rHCdo KyvHzV4bFPCC5X3oC7aVd+p2CKWpLX25qePokUA/gw92HHdKS3aeNiv895tvA6ekcU/c7sRv tfa8ygE5VY5brxVvdJKZOVf9ULKq99RZOTNCe8RcxYTtRRTOcKfv28VQezeEY1MRRybThuhn 1ZwfJ7Ac7ruR167DtLmX9bkSS3FGoqEWc1FxIgADR2uRfQIAAA== Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments 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, 21 Feb 2015 13:11:31 -0000 SGkgRGFuLA0KDQo+Pj4gLSBGb3Igbm92aWNlIChJRVNHKSByZWFkZXJzLCBpZiAnU0NUUG9EVExT JyBtZWFucyBzb21ldGhpbmcgZGlmZmVyZW50IHRoYW4gJ1NDVFAgb3Zlcg0KPj4+IERUTFMnLCB5 b3Ugc2hvdWxkIGFkZCB0aGF0IGV4cGxhbmF0aW9uIGluIHNlY3Rpb24gMiB3aGVyZSB5b3UgZGVm aW5lICdTQ1RQb0RUTFMnLsKgIE90aGVyd2lzZSwNCj4+PiB1c2UgdGhlIHNhbWUgdGVybSBldmVy eXdoZXJlLg0KPj4NCj4+IFNlY3Rpb24gMiBkb2VzIHNheToNCj4+DQo+PsKgIMKgIMKgIMKgICJT Q1RQb0RUTFMgYXNzb2NpYXRpb24gcmVmZXJzIHRvIGFuIFNDVFAgYXNzb2NpYXRpb24gY2Fycmll ZCBvdmVyIGFuDQo+PsKgIMKgIMKgIMKgIERUTFMgY29ubmVjdGlvbiBbSS1ELmlldGYtdHN2d2ct c2N0cC1kdGxzLWVuY2Fwc10uIg0KPj4NCj4+IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hh dCB5b3Ugd2FudCBtZSB0byBhZGQ/DQo+DQo+IEluIG11bHRpcGxlIGxvY2F0aW9ucyB5b3UgdXNl ICJTQ1RQIG92ZXIgRFRMUyIsIGluIHF1b3RlcywgdG8gdGFsayBhYm91dCANCj4gU0NUUCBvdmVy IERUTFMuwqAgWW91IGRvIGRlZmluZSAnU0NUUG9EVExTID4gYXNzb2NpYXRpb24nLsKgIEknbSBq dXN0IHNheWluZyANCj4gdGhhdCB5b3Ugc2hvdWxkIGVpdGhlciB1c2UgJ1NDVFBvRFRMUycgb3Ig IlNDVFAgb3ZlciBEVExTIiBldmVyeXdoZXJlLsKgIA0KPiBJbiB0aGUgY2FzZSBvZiB0aGUgYXNz b2NpYXRpb24gaXQgd291bGQgdGhlbiBlaXRoZXIgYmUgJ1NDVFBvRFRMUyBhc3NvY2lhdGlvbicg DQo+IG9yICdTQ1RQIG92ZXIgRFRMUyBhc3NvY2lhdGlvbicsIHdoaWNoZXZlciB5b3UgaGFkIGNo b3Nlbi7CoCBUaGUgZmFjdCB0aGF0IHlvdSB1DQo+IHNlICdTQ1RQb0RUTFMnIGNvdWxkIG1ha2Ug c29tZW9uZSB3b25kZXIgaWYgeW91IGRvbid0IG1lYW4gIlNDVFAgb3ZlciBEVExTIiANCj4gd2hl biB5b3UgdXNlIGl0LsKgIA0KwqANCkFhYWFoLCBub3cgSSBnb3QgaXQgOikNCg0KVW5sZXNzIEkn dmUgbWlzc2VkIGl0LCB0aGUgb25seSBwbGFjZSB3aGVyZSBJIHVzZSAiU0NUUCBvdmVyIERUTFMi IGlzIHdoZXJlIEkgcmVmZXIgdG8gdGhlIFNEUCBkYXRhIGNoYW5uZWwgbmVnb3RpYXRpb24gZHJh ZnQuDQoNCk9mIGNvdXJzZSwgSSBjb3VsZCBjaGFuZ2UgYWxsIGluc3RhbmNlcyBvZiAiU0NUUG9E VExTIiB0byAiU0NUUCBvdmVyIERUTFMiLiBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgb2YgdGhlbSwg dGhvdWdoLCBzbyBJIHRoaW5rIHRoZSB0ZXh0IGNvdWxkIGJlY29tZSByYXRoZXIgY2x1bXN5Lg0K DQpQZXJoYXBzIEkgY291bGQgZml4IHRoaXMgYnkgbW9kaWZ5aW5nIHRoZSBzZWN0aW9uIDIgdGV4 dCB0bzoNCg0KCSJTQ1RQb0RUTFMgKFNDVFAgb3ZlciBEVExTKSBhc3NvY2lhdGlvbiByZWZlcnMg dG8gYW4gU0NUUCBhc3NvY2lhdGlvbiANCgljYXJyaWVkIG92ZXIgYW5jRFRMUyBjb25uZWN0aW9u IFtJLUQuaWV0Zi10c3Z3Zy1zY3RwLWR0bHMtZW5jYXBzXS4iDQoNCi0tLS0tLS0tLS0tLS0tLQ0K DQo+PiAtIFNpbWlsYXJseSwgY2FwaXRhbGl6YXRpb24gb2YgRGF0YSBDaGFubmVsLCBlLmcuLCBp biAnV2ViUlRDIERhdGEgQ2hhbm5lbCcsIGlzIGluY29uc2lzdGVudC7CoCBQaWNrIG9uZSBzdHls ZSBhbmQgdXNlIGl0IGV2ZXJ5d2hlcmUuDQo+DQo+IEknbGwgdXNlIHNtYWxsIGxldHRlcnMgZm9y IG5vdy4gT25jZSB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBkcmFmdCBpcyByZWFkeSwgSSdsbCBh bGlnbi4NCg0KSnVzdCBrZWVwaW5nIHRoaXMgYXMgYSBwbGFjZSBob2xkZXIgOikNCg0KLS0tLS0t LS0tLS0tLS0tDQoNClNlY3Rpb24gMS4NCg0KPj4gRG8gd2UgcmVhbGx5IHdhbnQgdG8gY29uZnVz ZSBwZW9wbGUgd2l0aCB0aGUgdGV4dA0KPj4gJ8KgIE5PVEU6IFRoZSB1c2FnZSBvZiB0aGUgRGF0 YSBDaGFubmVsIEVzdGFibGlzaG1lbnQgUHJvdG9jb2wgKERDRVApDQo+PsKgwqAgW0ktRC5pZXRm LXJ0Y3dlYi1kYXRhLXByb3RvY29sXSBmb3IgZXN0YWJsaXNoaW5nIGEgQ0xVRSBkYXRhIGNoYW5u ZWwNCj4+wqDCoCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAnDQo+PiBp biB0aGUgZG9jdW1lbnQgc2luY2Ugd2UgZXNzZW50aWFsbHkgcmVxdWlyZSB1c2Ugb2Ygc2RwbmVn P8KgIE9yIGRvIHdlIGFjdHVhbGx5IHBlcm1pdCBvdGhlciB3YXlzIHRvIHNldCB1cCBDTFVFIGRh dGENCj4+IGNoYW5uZWxzP8KgIElmIHdlIGRvIHBlcm1pdCBvdGhlciB3YXlzLCB0aGlzIHRleHQg c2hvdWxkIHByb2JhYmx5IGJlIG1hZGUgbW9yZSBnZW5lcmljIGluIGV4cGxhaW5pbmcgdGhhdCB3 ZSBkZWZpbmUgb25seSBvbmUNCj4+IHdheSB0byBlc3RhYmxpc2ggQ0xVRSBkYXRhIGNoYW5uZWxz LCBkbyBub3QgZm9yYmlkIG90aGVyIHdheXMsIGJ1dCBhbnkgb3RoZXIgd2F5IChzdWNoIGFzIERD RVApIGlzIG91dCBvZiBzY29wZS4NCj4NCj4gSSB0aGluayB0aGUgbm90ZSBpcyB1c2VmdWwsIGJl Y2F1c2UgdGhlIFdlYlJUQyBkYXRhIGNoYW5uZWwgZHJhZnQgZG9lcyBtZW50aW9uIERDRVAgYXMg YSBtZWNoYW5pc20gZm9yIGVzdGFibGlzaGluZyBkYXRhIA0KPiBjaGFubmVscy4gQW5kLCBpbiBt eSBvcGluaW9uICJvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IiBkb2VzIG1lYW4g dGhhdCBvdGhlcnMgY2FuIGRlZmluZSBpdCA6KQ0KPg0KPiBIb3cgYWJvdXQgdGhpcz/CoCBSZXBs YWNlIHRoZSB0ZXh0IEkgcXVvdGUgYWJvdmUgd2l0aA0KPg0KPifCoCBOT1RFOsKgIFRoaXMgc3Bl Y2lmaWNhdGlvbiBkZWZpbmVzIG9ubHkgb25lIHdheSB0byBlc3RhYmxpc2ggZGF0YSBjaGFubmVs cy7CoCBUaGUgDQo+IG1lY2hhbmlzbSBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBk aWZmZXJlbnQgZnJvbSB0aGUgRGF0YSBDaGFubmVsIA0KPiBFc3RhYmxpc2htZW50IFByb3RvY29s IFtJLUQuaWV0Zi1ydGN3ZWItZGF0YS1wcm90b2NvbF0gZGVmaW5lZCBmb3IgV2ViUlRDIGRhdGEg DQo+IGNoYW5uZWxzLiBEZWZpbml0aW9uIGFuZC9vciB1c2FnZSBvZiBhbnkgcHJvdG9jb2wgZm9y IGVzdGFibGlzaGluZyBDTFVFIGRhdGEgY2hhbm5lbHMgDQo+IG90aGVyIHRoYW4gdGhhdCBkZWZp bmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1l bnQuJw0KDQpJIHRoaW5rIHlvdXIgc3VnZ2VzdGVkIHRleHQgbWF5IGNhdXNlIHNvbWUgY29uZnVz aW9uLCBiZWNhdXNlIHRoZSB3YXkgSSByZWFkIHRoZSB0ZXh0LCBpdCB0YWxrcyBhYm91dCAiV2Vi UlRDIGRhdGEgY2hhbm5lbHMiIGFuZCAiQ0xVRSBkYXRhIGNoYW5uZWxzIiBhcyB0d28gc2VwYXJh dGUgdGhpbmdzLiBXZWJSVEMgZGF0YSBjaGFubmVsIGlzIGEgbWVjaGFuaXNtLCBhbmQgdGhlIENM VUUgZGF0YSBjaGFubmVsIGlzIGEgdXNhZ2Ugb2YgdGhhdCBXZWJSVEMgZGF0YSBjaGFubmVsIG1l Y2hhbmlzbSA6KQ0KDQotLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiAzLg0KDQo+PiBJIGRvbid0 IGtub3cgd2hldGhlciBpdCBiZWxvbmdzIGhlcmUgb3IgaW4gc2VjdGlvbiAxLCBidXQgaXQgbWln aHQgaGVscCBhIG5vdmljZSByZWFkZXIgdG8gc2F5IGEgbGl0dGxlIG1vcmUgYWJvdXQgdGhlIHJl bGF0aW9uc2hpcCA+PiBiZXR3ZWVuIFdlYlJUQyBkYXRhIGNoYW5uZWxzIGFuZCBDTFVFIGRhdGEg Y2hhbm5lbHMgYXMgY29udGV4dC7CoCBKdXN0IGEgZmV3IHNlbnRlbmNlcyBtaWdodCBoZWxwLsKg IEZvciBleGFtcGxlLCB0aGUgZmlyc3QNCj4+IHBhcmFncmFwaCBpbiAzLjEgY291bGQgYmUgY2hh bmdlZCB0bw0KPj4NCj4+ICdUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSByZWFsaXphdGlvbiBv ZiBhIENMVUUgZGF0YSBjaGFubmVsIHVzaW5nIGEgV2ViUlRDIGRhdGEgY2hhbm5lbC7CoCBUaGUg V2ViUlRDIERhdGEgQ2hhbm5lbCB3YXMNCj4+IGRldmVsb3BlZCB0byBwcm92aWRlIGEgc2ltcGxl IG1lY2hhbmlzbSBmb3IgdHdvIGVuZHBvaW50cywgZm9yIGV4YW1wbGUgdHdvIHdlYiBicm93c2Vy cywgdG8gZXN0YWJsaXNoIGNoYW5uZWxzIGZvciBjYXJyeWluZw0KPj4gYXJiaXRyYXJ5IGRhdGEu wqAgVGhlIFdlYlJUQyBEYXRhIENoYW5uZWwgYWNjb21wbGlzaGVzIHRoaXMgYnkgY3JlYXRpbmcg U0NUUCBzdHJlYW1zIG92ZXIgYSBEVExTIGNvbm5lY3Rpb24uwqAgVGhlIGRldGFpbHMgYXJlDQo+ PiBkZXNjcmliZWQgaW4gW0ktRC5pZXRmLXJ0Y3dlYi1kYXRhLWNoYW5uZWxdLsKgIEFkZGl0aW9u YWwgaXRlbXMgbmVlZCB0byBiZSBkZWZpbmVkIGluIG9yZGVyIHRvIHVzZSBhIFdlYlJUQyBkYXRh IGNoYW5uZWwgYXMgYQ0KPj4gQ0xVRSBkYXRhIGNoYW5uZWw6wqAgYSBzZXQgb2YgU0NUUCBjaGFy YWN0ZXJpc3RpY3Mgc3BlY2lmaWMgdG8gYSBDTFVFIGRhdGEgY2hhbm5lbCwgdGhlIHZhbHVlcyBv ZiB0aGUgbS0gbGluZSBkZXNjcmliaW5nIHRoZQ0KPj4gU0NUUG9EVExTIGFzc29jaWF0aW9uIGFz c29jaWF0ZWQgd2l0aCB0aGUgV0VCUlRDIERhdGEgQ2hhbm5lbCwgYW5kIHRoZSB1c2FnZSBvZiB0 aGUgU0RQLWJhc2VkICJTQ1RQIG92ZXIgRFRMUyIgZGF0YQ0KPj4gY2hhbm5lbCBuZWdvdGlhdGlv biBtZWNoYW5pc20gZm9yIGNyZWF0aW5nIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4nDQo+DQo+IEkg Y2FuIGRvIHRoZSBtb2RpZmljYXRpb24gaW4gLTA5Lg0KDQpJIGhhZCBhIGNsb3NlciBsb29rIGF0 IHRoaXMsIGFuZCBjb21wYXJlZCBpdCB0byB0aGUgZXhpc3RpbmcgdGV4dCBpbiB0aGUgZHJhZnQs IGFuZCBJJ2QgbGlrZSB0byBzdWdnZXN0IGEgbGl0dGxlIGRpZmZlcmVudCB2ZXJzaW9uLg0KDQpG aXJzdCwgc2VjdGlvbiAxIGFscmVhZHkgc2F5czoNCg0KCSJUaGlzIGRvY3VtZW50IGRlZmluZXMg aG93IHRvIHVzZSB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBtZWNoYW5pc20gaW4gb3JkZXIgdG8g cmVhbGl6ZWQgYSBkYXRhIGNoYW5uZWwsDQoJUmVmZXJyZWQgdG8gYXMgQ0xVRSBkYXRhIGNoYW5u ZWwsIGZvciB0cmFuc3BvcnRpbmcgQ0xVRSBwcm90b2NvbCBtZXNzYWdlcyBiZXR3ZWVuIHR3byBD TFVFIGVuZHBvaW50cy4iDQoNClNvLCBJIHRoaW5rIHRoZSAicmVsYXRpb25zaGlwIGlzIGFscmVh ZHkgdGhlcmUiLg0KDQpJbiBhZGRpdGlvbiwgc2VjdGlvbiAxIGFsc28gdGFsa3MgYWJvdXQgdXNh Z2Ugb2YgU0NUUCBvdmVyIERUTFMuDQoNClNvLCBteSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIG9u bHkgbW9kaWZ5IHRoZSBmaXJzdCBzZW50ZW5jZSBpbiBzZWN0aW9uIDMuMSB0bzoNCg0KCSJUaGlz IHNlY3Rpb24gZGVzY3JpYmVzIHRoZSByZWFsaXphdGlvbiBvZiBhIENMVUUgZGF0YSBjaGFubmVs LCB1c2luZyB0aGUgV2ViUlRDIGRhdGEgY2hhbm5lbCBtZWNoYW5pc20uIg0KDQouLi5hbmQga2Vl cCB0aGUgcmVzdCBhcyBpdCBpcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From nobody Sat Feb 21 08:36:53 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39D91A6FED for ; Sat, 21 Feb 2015 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, 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 AOxa5jzIBbtt for ; Sat, 21 Feb 2015 08:36:51 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [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 795841A0267 for ; Sat, 21 Feb 2015 08:36:51 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-07v.sys.comcast.net with comcast id v4cC1p0072Bo0NV014cq2B; Sat, 21 Feb 2015 16:36:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-05v.sys.comcast.net with comcast id v4cp1p0063Ge9ey014cp5b; Sat, 21 Feb 2015 16:36:50 +0000 Message-ID: <54E8B41F.2040008@alum.mit.edu> Date: Sat, 21 Feb 2015 11:36:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D70EB27@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D70EB27@ESESSMB209.ericsson.se> 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=1424536610; bh=nTcHu5eeIBAfD5ZkcxmL17TR5EZhUsS+1ZBlmuJXakk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Y4LI2SwH0VYIJil4/hPnF7c1fnKZBikRLg69i5Hg0b2+UOGXy26ZQtKAfGng3pPbu +a0Q11WgdX5OUvd3qd1D99t7uop5L0H0dgaFh2pPJa+CyKfeZ75Jw4q9FdEWNAM4Pt MhRSNzIQr8eoZV5sZ4TVGAubsUsi0hIRb9fPjF20RjXB+Ev3Y4dM4PU3CFOwuht/h1 grM0nYkxpACSsvdyloNi43ebgAWqMJbt5BIc4wz2rPg6w3miEGZvu1CJe7WUfMCMmU HMYWTafo35WG+5wAzrYXKbH/oxKTrz+NkokMFFDnSs0K7lgtGnOzBIZkJJvLKiBZ+r duVvri123Nd4g== Archived-At: Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments 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, 21 Feb 2015 16:36:53 -0000 On 2/21/15 8:11 AM, Christer Holmberg wrote: > Hi Dan, > >>>> - For novice (IESG) readers, if 'SCTPoDTLS' means something different than 'SCTP over >>>> DTLS', you should add that explanation in section 2 where you define 'SCTPoDTLS'. Otherwise, >>>> use the same term everywhere. >>> >>> Section 2 does say: >>> >>> "SCTPoDTLS association refers to an SCTP association carried over an >>> DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]." >>> >>> I'm not sure I understand what you want me to add? >> >> In multiple locations you use "SCTP over DTLS", in quotes, to talk about >> SCTP over DTLS. You do define 'SCTPoDTLS > association'. I'm just saying >> that you should either use 'SCTPoDTLS' or "SCTP over DTLS" everywhere. >> In the case of the association it would then either be 'SCTPoDTLS association' >> or 'SCTP over DTLS association', whichever you had chosen. The fact that you u >> se 'SCTPoDTLS' could make someone wonder if you don't mean "SCTP over DTLS" >> when you use it. > > Aaaah, now I got it :) > > Unless I've missed it, the only place where I use "SCTP over DTLS" is where I refer to the SDP data channel negotiation draft. > > Of course, I could change all instances of "SCTPoDTLS" to "SCTP over DTLS". There are quite a few of them, though, so I think the text could become rather clumsy. I think it would be good to be consistent, one way or the other. I don't feel strongly - I can live with either. I will say that *perhaps* "SCTP over DTLS" would be more readable without expanding the text much. That avoids the need for a definition that some readers apparently miss. This might be something to discuss with the rfc editor when it gets that far. Thanks, Paul From nobody Sat Feb 21 08:55:18 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5431D1A702D for ; Sat, 21 Feb 2015 08:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rww3Yb8v6InE for ; Sat, 21 Feb 2015 08:55:15 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB1D1A6FED for ; Sat, 21 Feb 2015 08:55:14 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-c9-54e8b8707188 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.93.04231.078B8E45; Sat, 21 Feb 2015 17:55:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Sat, 21 Feb 2015 17:54:48 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments Thread-Index: AQHQR+OVbK2kyPdsUEOggVHLuVK2NZz4UL2AgALA7JCAADb3gIAAFc3V Date: Sat, 21 Feb 2015 16:54:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D70ED31@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D6D2A14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D70EB27@ESESSMB209.ericsson.se>, <54E8B41F.2040008@alum.mit.edu> In-Reply-To: <54E8B41F.2040008@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D70ED31ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM2K7pW7BjhchBu9bpCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8rY+xoKDlhU7mxawNzDuNOhi5OSQEDCR eN62hRXCFpO4cG89WxcjF4eQwGFGiX9/l7NDOEsYJZ7M/w1UxcHBJmAh0f1PG6RBRMBTYsfH KcwgtrBAmETLu5fsEPFwiV8rt7NB2G4Sj87NBqthEVCV6Gg+zARi8wr4Svy438MEMX8/k8T3 1d8ZQRKcAjoSXVubwRoYgS76fmoNWAOzgLhE05eVUJcKSCzZc54ZwhaVePn4H9htzAL5Evf/ 8ULMF5Q4OfMJywRG4VlIumchVM1CUgVRYiDx5f1tKFtbYtnC18wQtr5E9/vTTMjiCxjZVzGK FqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERs/BLb91dzCufu14iFGAg1GJh3fDl+chQqyJZcWV uYcYpTlYlMR57YwPhQgJpCeWpGanphakFsUXleakFh9iZOLglGpgXNuo/Ow4h1tMPGPQVLW0 eWdfL7TPuaLmfmD95vIn/RveGv685f8kJuWIx7UfEftexe5ubLhfyaf69OC3ismXtujYfP8a FLRfS2lTpkd3p9Wtzwnd33/nxDqcO+2h9FTh8e+pzuyBvD+Y/jeeiyk5K/hGvrJPU4/5m0bV Nmnm0vsp3xY3CUUYK7EUZyQaajEXFScCAIbsZ8B/AgAA Archived-At: Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments 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, 21 Feb 2015 16:55:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D70ED31ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, You can try by doing a seach/replace (SCTPoDTLS -> SCTP over DTLS). Again, I only use SCTP over DTLS when I am writing the subject of Richard's= draft. But, I could of course NOT write the subject of the draft, but only the dra= ft name. Regards, Christer Sent from my Windows Phone ________________________________ From: Paul Kyzivat Sent: =FD21/=FD02/=FD2015 18:36 To: clue@ietf.org Subject: Re: [clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB= comments On 2/21/15 8:11 AM, Christer Holmberg wrote: > Hi Dan, > >>>> - For novice (IESG) readers, if 'SCTPoDTLS' means something different = than 'SCTP over >>>> DTLS', you should add that explanation in section 2 where you define '= SCTPoDTLS'. Otherwise, >>>> use the same term everywhere. >>> >>> Section 2 does say: >>> >>> "SCTPoDTLS association refers to an SCTP association carried o= ver an >>> DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps]." >>> >>> I'm not sure I understand what you want me to add? >> >> In multiple locations you use "SCTP over DTLS", in quotes, to talk about >> SCTP over DTLS. You do define 'SCTPoDTLS > association'. I'm just sayi= ng >> that you should either use 'SCTPoDTLS' or "SCTP over DTLS" everywhere. >> In the case of the association it would then either be 'SCTPoDTLS associ= ation' >> or 'SCTP over DTLS association', whichever you had chosen. The fact tha= t you u >> se 'SCTPoDTLS' could make someone wonder if you don't mean "SCTP over DT= LS" >> when you use it. > > Aaaah, now I got it :) > > Unless I've missed it, the only place where I use "SCTP over DTLS" is whe= re I refer to the SDP data channel negotiation draft. > > Of course, I could change all instances of "SCTPoDTLS" to "SCTP over DTLS= ". There are quite a few of them, though, so I think the text could become = rather clumsy. I think it would be good to be consistent, one way or the other. I don't feel strongly - I can live with either. I will say that *perhaps* "SCTP over DTLS" would be more readable without expanding the text much. That avoids the need for a definition that some readers apparently miss. This might be something to discuss with the rfc editor when it gets that far. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1D70ED31ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

You can try by doing a seach/replace (SCTPoDTLS -> SCTP over DTLS).

Again, I only use SCTP over DTLS when I am writing the subject of Richard's= draft.

But, I could of course NOT write the subject of the draft, but only the dra= ft name.

Regards,

Christer

Sent from my Windows Phone
From: Paul Kyzivat
Sent: =FD21= /=FD02/=FD2015 18:36
To: clue@ietf.org
Subject: Re: [= clue] draft-clue-data-channel-07(no, -08) WGLC review -- DanB comments

On 2/21/15 8:11 AM, Christer Holmberg wrote:
> Hi Dan,
>
>>>> - For novice (IESG) readers, if 'SCTPoDTLS' means somethin= g different than 'SCTP over
>>>> DTLS', you should add that explanation in section 2 where = you define 'SCTPoDTLS'.  Otherwise,
>>>> use the same term everywhere.
>>>
>>> Section 2 does say:
>>>
>>>          "SC= TPoDTLS association refers to an SCTP association carried over an
>>>          DTLS con= nection [I-D.ietf-tsvwg-sctp-dtls-encaps]."
>>>
>>> I'm not sure I understand what you want me to add?
>>
>> In multiple locations you use "SCTP over DTLS", in quote= s, to talk about
>> SCTP over DTLS.  You do define 'SCTPoDTLS > association'.&= nbsp; I'm just saying
>> that you should either use 'SCTPoDTLS' or "SCTP over DTLS&quo= t; everywhere.
>> In the case of the association it would then either be 'SCTPoDTLS = association'
>> or 'SCTP over DTLS association', whichever you had chosen.  T= he fact that you u
>> se 'SCTPoDTLS' could make someone wonder if you don't mean "S= CTP over DTLS"
>> when you use it.
>
> Aaaah, now I got it :)
>
> Unless I've missed it, the only place where I use "SCTP over DTLS= " is where I refer to the SDP data channel negotiation draft.
>
> Of course, I could change all instances of "SCTPoDTLS" to &q= uot;SCTP over DTLS". There are quite a few of them, though, so I think= the text could become rather clumsy.

I think it would be good to be consistent, one way or the other. I don't feel strongly - I can live with either.

I will say that *perhaps* "SCTP over DTLS" would be more readable=
without expanding the text much. That avoids the need for a definition
that some readers apparently miss. This might be something to discuss
with the rfc editor when it gets that far.

        Thanks,
        Paul

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B1D70ED31ESESSMB209erics_-- From nobody Sat Feb 21 23:19:37 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125C81A1AB8 for ; Sat, 21 Feb 2015 23:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 LjrrqVOJ0v22 for ; Sat, 21 Feb 2015 23:19:34 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 2C3281A03E3 for ; Sat, 21 Feb 2015 23:19:34 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so10680193wiw.3 for ; Sat, 21 Feb 2015 23:19:32 -0800 (PST) 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=wlNYlNL2SWMf11ybBCU4kediwjyTH5eLVpDtRuy1EDU=; b=qvSveo2v4LPDzXQpaYA+s4jA0u55bpeHW2wns3EvJ/fMjK04eUCyh2iQ1XwSIylXgb Kxv4KICC1HJvqt7y8vZTFFhL4BX0Svt7d5RIbhHC4jHTIwlPGqLbvBEtfM3olj6C6blm DqJYlO5nFhsrezywRtfIFw9o6Qfm4M9+zx6H80z7e/n16scMoldJtuqRqtiOpuRU6ORg Clfr9+rrDWXrJPxkGnopFBdjCyctW6oYt+HCp5hK9EgmH/uPQ7Ul6TZrJ8d5+GSHLJHM XVADiSaMargMFEDyACxEIQdVFuosKcRSnSrlE55cx1auMLQfn09aAL5U1lOPoC+zmHmO DAhA== X-Received: by 10.195.12.71 with SMTP id eo7mr10882512wjd.3.1424589572756; Sat, 21 Feb 2015 23:19:32 -0800 (PST) Received: from RoniE (bzq-79-178-200-101.red.bezeqint.net. [79.178.200.101]) by mx.google.com with ESMTPSA id fo9sm10114792wib.16.2015.02.21.23.19.30 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 21 Feb 2015 23:19:32 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'Christian Groves'" , "'Stephan Wenger'" References: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEEEB@CRPMBOXPRD08.polycom.com> <01da01d04d2e$22b38890$681a99b0$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEFF6@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2BAEFF6@CRPMBOXPRD08.polycom.com> Date: Sun, 22 Feb 2015 09:19:28 +0200 Message-ID: <024401d04e6f$e7097f00$b51c7d00$@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: AQIsnBgtbNbH2J587NSpwewSMPADwAH3l9mdAX1sW9icJ/5v0A== Content-Language: en-us Archived-At: Cc: clue@ietf.org Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian comments 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, 22 Feb 2015 07:19:36 -0000 Mark thanks, My comment about the first issue was that a consumer getting a new advertisement have to acknowledge it but is not required to send a configure if no change is needed. I agree that the text is not clear enough, so maybe clarifying what optional means is another way to address the issue and it will be good to get more opinions specially from Stephan Roni > -----Original Message----- > From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com] > Sent: 21 February, 2015 1:05 AM > To: Roni Even; 'Christian Groves'; Stephan Wenger (stewe@stewe.org) > Cc: clue@ietf.org > Subject: RE: [clue] short WGLC on draft-ietf-clue-framework-20 - Christian > comments > > I plan to submit an updated framework draft around March 3. I'll be on > vacation until then. I have several minor updates done, based on latest > feedback from Christian and Paul. > > I'm not sure about the first issue about protocol mechanisms being optional. > I've asked Stephan about it, as I think he wrote that part. > > I expect for the second issue below, I will remove the restriction (as both > Christian and Roni suggest) unless people start objecting. > > Mark > > > -----Original Message----- > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > > Sent: Friday, February 20, 2015 11:56 AM > > To: Duckworth, Mark; 'Christian Groves'; clue@ietf.org > > Subject: RE: [clue] short WGLC on draft-ietf-clue-framework-20 - > > Christian comments > > > > Hi, > > Inline > > Roni as individual > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, > > > Mark > > > Sent: 20 February, 2015 1:41 AM > > > To: Christian Groves; clue@ietf.org > > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 - > > > Christian comments > > > > > > A couple of Christian's items remain in discussion... > > > > > > > -----Original Message----- > > > > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > > > > Sent: Monday, February 16, 2015 7:39 AM > > > > To: Duckworth, Mark; clue@ietf.org > > > > Subject: Re: [clue] short WGLC on draft-ietf-clue-framework-20 > > > > > > > > >> 4. Section 5 pg15 2nd para: It says all CLUE protocol > > > > >> mechanisms are optional in the consumer and that it is free to > > > > >> ignore the > > information. > > > > >> Whilst its true for the Advertisement I don't think this is > > > > >> generally true. It shouldn't ignore the Options message. > > > > > [Duckworth, Mark] I think it's okay the way it is. The protocol > > > > > document > > > > has the details. > > > > [CNG] Then why don't we remove the sentence and really leave it up > > > > to the protocol document? I think we're really only talking about > > > > the Advertisement and even for that is it true. i.e. the Consumer > > > > shouldn't ignore the "allow subset choice" parameter. > > > > > > [Duckworth, Mark] The sentence we are talking about is: > > > " All CLUE protocol mechanisms are OPTIONAL in the Consumer in the > > sense > > > that, > > > while the Consumer MUST be able to receive (and, potentially, > > > gracefully acknowledge) CLUE messages, it is free to ignore the > > > information provided therein." > > > [Duckworth, Mark] On second thought, I think it is good to remove > > > this sentence. But I'm hoping to get more people to agree before I > > > take it > > out. > > > The signaling document says the Provider can't send media until it > > receives a > > > Configure message. So I think it really isn't optional at all, and > > > a > > Consumer > > > must send a valid Configure message if it wants to receive media. > > [Roni Even] I am not sure what is discussed, the example " allow > > subset choice" given by Christian is sent by the provider and the > > consumer may ignore it and not ask for subsets. > > Having said that, reading the paragraph it talks about the renderer in > > the consumer and the consumer. I am not sure why we have the > > distinction since we are talking about the consumer and it looks to me > > like the last sentence in the paragraph is the same as the sentence > > before that talks about the renderer in the consumer. > > My reading is that the consumer MUST send at least advertisement > > acknowledge (as defined in the CLUE protocol) and may send a > > configure, this means the an advertisement may be ignore and not > > require a configure message. > > > > Roni > > > > > > > > > >> 6. Section 7.1.1.13: "This attribute is only applicable to > > > > >> video Captures and presentation streams with visual > > > > >> information." Could this also be applicable to audio captures? > > > > >> i.e. lyrics along with > > audio. > > > > > [Duckworth, Mark] I don't remember why that restriction was added. > > > > > Was > > > > that in your original proposal for this attribute? It is okay > > > > with me to remove this sentence. > > > > [CNG] Yes it was the original based on a comment I received. In > > > > hindsight I don't think I should have proposed it. > > > > > > [Duckworth, Mark] We are talking about the "embedded text" attribute. > > > Based on the description " a Capture provides embedded textual > > information. > > > For example the video Capture MAY contain speech to text information > > > composed with the video image," it still seems to me this applies > > > only to > > video. > > > I don't understand how embedded text could be added to an audio > > encoding > > in > > > this sense, as I understood it to mean the text would just appear in > > > the > > decoded > > > and rendered media without any additional processing. > > > Does anybody else want to comment? > > [Roni Even] Looking at previous discussion it said that if we will > > need something for audio it will be a new attribute. Anyhow I do not > > have any objection to remove the restriction. > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Feb 23 06:27:46 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5831A1AC6 for ; Mon, 23 Feb 2015 06:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_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 vqLKxL3emi2o for ; Mon, 23 Feb 2015 06:27:43 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 6F5911A1ABB for ; Mon, 23 Feb 2015 06:27:43 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id hi2so17584618wib.4 for ; Mon, 23 Feb 2015 06:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=RWMGIhnbq8OUcApF7d+P888orZqTOdEgBasSRI4oyXA=; b=vLhJi91Jsy/VoyHHetiOV1yrBECyVxy8hkjIz9mxC3YMXrRz3VXkTsig+WAeD3W5L0 d+et0J369aldMSV9dLvsnzTu+n4S+klvXO5OPiz3IjIR+qXOebh3USnjC41QLC8Lsk1f /wJE4yRiaOZrRDawe5+heRr2jwGGeUpta6FQ58+28a+BagkV8EbCITxISaJCXdkKwCMs KNF0/EXq6X+GcTDuGRvIGYsyrDdsk7iUDOxlPTlxZnbINg3FuMJyHj7Z5zO9Qi/fRmaA jL71facZFHIKiFcjk882yc74x7MnO/b8KbAIfWu9imOzvFFyLxbk6Ejcq5Wve0DXpsxt oNVA== X-Received: by 10.181.12.105 with SMTP id ep9mr21324363wid.85.1424701661152; Mon, 23 Feb 2015 06:27:41 -0800 (PST) Received: from RoniE (bzq-79-177-192-183.red.bezeqint.net. [79.177.192.183]) by mx.google.com with ESMTPSA id ka1sm55817085wjc.2.2015.02.23.06.27.38 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Feb 2015 06:27:40 -0800 (PST) From: "Roni Even" To: Date: Mon, 23 Feb 2015 16:27:15 +0200 Message-ID: <02e601d04f74$e0b7b1c0$a2271540$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E7_01D04F85.A440F6F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBPdNHXrEJZ6hoXRK6FWgbtDCB4sw== Content-Language: en-us Archived-At: Subject: [clue] Liaison from 3GPP S$ X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 14:27:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E7_01D04F85.A440F6F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We received the following liaison from 3GPP S4, please review and if you have any feedback please respond to the list http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/S4-150241% 20LS%20to%20IETF%20CLUE%20WG%20on%20media%20handling%20aspects%20related%20t o%20CLUE%20protocol.doc http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/SP-140483_ S4-140989%20Rel-13_WID%20IMS_TELEP.doc Thanks Roni Even CLUE co-chair ------=_NextPart_000_02E7_01D04F85.A440F6F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We received the = following liaison from 3GPP S4, please review and if you have any = feedback please respond to the list

 

http://trac.tools.ietf.org/wg/clue= /trac/attachment/wiki/WikiStart/S4-150241%20LS%20to%20IETF%20CLUE%20WG%20= on%20media%20handling%20aspects%20related%20to%20CLUE%20protocol.doc<= o:p>

 

http://trac.tools.ietf= .org/wg/clue/trac/attachment/wiki/WikiStart/SP-140483_S4-140989%20Rel-13_= WID%20IMS_TELEP.doc

 

 

Thanks

Roni = Even

CLUE = co-chair

------=_NextPart_000_02E7_01D04F85.A440F6F0--