From nobody Wed Apr 1 00:58: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 B4E9E1A8A49 for ; Wed, 1 Apr 2015 00:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvAryjedQCvo for ; Wed, 1 Apr 2015 00:58:22 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E063D1A8A4D for ; Wed, 1 Apr 2015 00:58:20 -0700 (PDT) X-AuditID: c1b4fb2d-f79a46d0000006b4-92-551ba51ac713 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D9.8C.01716.A15AB155; Wed, 1 Apr 2015 09:58:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.236]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Wed, 1 Apr 2015 09:58:18 +0200 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling draft Thread-Index: AdBr3gvaWasfKkPpT2Kn9uC6tzdGpgAc1/HQ Date: Wed, 1 Apr 2015 07:58:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> References: <00be01d06bde$1355b480$3a011d80$@gmail.com> In-Reply-To: <00be01d06bde$1355b480$3a011d80$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D787868ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM+Jvja70UulQg54VzBb7T11mtvjbzuzA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZazv+Mde0BFZcbW7k72Bcbt/FyMHh4SAicTR bqUuRk4gU0ziwr31bF2MXBxCAkcZJSacaoRyFjNK7Jw4jRGkgU3AQqL7nzZIg4iAu0TT84Xs ILawQKzErYkLmSDicRKfn65kg7CNJP4eXcwC0soioCKx75wUSJhXwFfizLZXLCC2kIC5xNKH 78BaOYGm37z9khHEZgS65/upNWBxZgFxiVtP5jNB3CkgsWTPeWYIW1Ti5eN/rBCvKElM25oG UZ4v0TXzLRvEKkGJkzOfsExgFJmFZNIsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4 Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB8XRwy2/dHYyrXzseYhTgYFTi4U3olA4V Yk0sK67MPcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj4TElPQ9rAdXX Ozuv+l9sk1Netq12p82Rib+ZjtSwuSg4FShujSk+PuWLcnPK7XXO/yc91V9zs1729tkWWxlN 04MMJ2X+u10xmHjLvSbCU9WmjjGk3Gpbwhp5u4CX070dF1+zmVAf/+N5UP93vugYkR+TJ5/N aV461dWq8Lb20VcRd/REt3gqsRRnJBpqMRcVJwIAvOcXqYgCAAA= Archived-At: Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 01 Apr 2015 07:58:23 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D787868ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support 2) or 3), and the when-not-to-use text would indicate that there = are environments where media is protected using other means. Regards, Christer From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 31. maaliskuuta 2015 21:11 To: clue@ietf.org Subject: [clue] call on Mandating using DTLS/SRTP for all media in CLUE sig= naling draft Hi, In IETF 91 there was according to the meeting notes Rough consensus in favo= r of mandating DTLS/SRTP for all media in CLUE signaling draft. There was n= o follow up discussion on the list. The topic was presented again in IETF92 and the comments were made for havi= ng DTLS/SRTP but Mandate only the support and not the use. The WG chairs are looking for which direction to take. I see three options 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 2. DTLS/SRTP MUST be supported (and have some text about when not to = use) 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text abou= t when not to use) Please provide feedback about which text to use by April 15th Note that the current text is option1 and if no comments it will need to st= ay Thanks Roni Even CLUE WG co-chair --_000_7594FB04B1934943A5C02806D1A2204B1D787868ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I suppo= rt 2) or 3), and the when-not-to-use text would indicate that there are env= ironments where media is protected using other means.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 31. maaliskuuta 2015 21:11
To: clue@ietf.org
Subject: [clue] call on Mandating using DTLS/SRTP for all media in C= LUE signaling draft

 

Hi,

In IETF 91 there was according to the meet=
ing notes Rough consensus in favor of mandating=
 DTLS/SRTP for all media in CLUE signaling draft. There was no follow up di=
scussion on the list.
The topic was presented again =
in IETF92 and the comments were made for having DTLS/SRTP but Mandate only =
the support and not the use.
 
The WG chairs are looking for =
which direction to take. I see three options
 
1.       DTLS/SRTP MUST be used as in the curren=
t 05 draft section 13
2.       DTLS/SRTP MUST be supported (and have s=
ome text about when not to use)
3.       DTLS/SRTP MUST be supported and SHOULD =
be used (and some text about when not to use)
 
Please provide feedback about =
which text to use by April 15th 
 
Note that the current text is =
option1 and if no comments it will need to stay
 
Thanks
Roni Even

CLUE WG co-chair


 
--_000_7594FB04B1934943A5C02806D1A2204B1D787868ESESSMB209erics_-- From nobody Wed Apr 1 02:49: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 22FED1A1A13 for ; Wed, 1 Apr 2015 02:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Lk0IcaIkWe5 for ; Wed, 1 Apr 2015 02:49:39 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5127D1A0B00 for ; Wed, 1 Apr 2015 02:49:39 -0700 (PDT) Received: from ppp118-209-246-136.lns20.mel8.internode.on.net ([118.209.246.136]:59742 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YdFGl-0001Mx-IC for clue@ietf.org; Wed, 01 Apr 2015 20:49:07 +1100 Message-ID: <551BBF2D.1040904@nteczone.com> Date: Wed, 01 Apr 2015 20:49:33 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <00be01d06bde$1355b480$3a011d80$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D787868@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] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 01 Apr 2015 09:49:41 -0000 +1 Christian On 1/04/2015 6:58 PM, Christer Holmberg wrote: > > Hi, > > I support 2) or 3), and the when-not-to-use text would indicate that > there are environments where media is protected using other means. > > Regards, > > Christer > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > *Sent:* 31. maaliskuuta 2015 21:11 > *To:* clue@ietf.org > *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in > CLUE signaling draft > > Hi, > > In IETF 91 there was according to the meeting notesRough consensus in favor of mandating DTLS/SRTP for all media in CLUE signaling draft. There was no follow up discussion on the list. > The topic was presented again in IETF92 and the comments were made for having DTLS/SRTP but Mandate only the support and not the use. > > The WG chairs are looking for which direction to take. I see three options > > 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 > 2. DTLS/SRTP MUST be supported (and have some text about when not to use) > 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text about when not to use) > > Please provide feedback about which text to use by April 15^th > > Note that the current text is option1 and if no comments it will need to stay > > Thanks > Roni Even > CLUE WG co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Apr 1 05:38: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 43CC11A88D0 for ; Wed, 1 Apr 2015 05:38:21 -0700 (PDT) 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 tXHklRe6JUjR for ; Wed, 1 Apr 2015 05:38:18 -0700 (PDT) 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 4FA781A8AC0 for ; Wed, 1 Apr 2015 05:38:18 -0700 (PDT) Received: from [216.82.254.20] by server-17.bemta-7.messagelabs.com id 47/95-02438-8B6EB155; Wed, 01 Apr 2015 12:38:16 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-47.messagelabs.com!1427891895!12993636!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27191 invoked from network); 1 Apr 2015 12:38:16 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-3.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 1 Apr 2015 12:38:16 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by Crpehubprd01.polycom.com ([::1]) with mapi; Wed, 1 Apr 2015 05:37:16 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 1 Apr 2015 05:38:13 -0700 Thread-Topic: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling draft Thread-Index: AdBsYRljsnH2PoPkR2m6PzV8DRyLNgAF5erg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2E856F3@CRPMBOXPRD08.polycom.com> References: <00be01d06bde$1355b480$3a011d80$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> <551BBF2D.1040904@nteczone.com> In-Reply-To: <551BBF2D.1040904@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] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 01 Apr 2015 12:38:21 -0000 +1 Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Wednesday, April 01, 2015 5:50 AM > To: clue@ietf.org > Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CL= UE > signaling draft >=20 > +1 >=20 > Christian >=20 > On 1/04/2015 6:58 PM, Christer Holmberg wrote: > > > > Hi, > > > > I support 2) or 3), and the when-not-to-use text would indicate that > > there are environments where media is protected using other means. > > > > Regards, > > > > Christer > > > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > > *Sent:* 31. maaliskuuta 2015 21:11 > > *To:* clue@ietf.org > > *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in > > CLUE signaling draft > > > > Hi, > > > > In IETF 91 there was according to the meeting notesRough consensus in f= avor > of mandating DTLS/SRTP for all media in CLUE signaling draft. There was n= o > follow up discussion on the list. > > The topic was presented again in IETF92 and the comments were made for > having DTLS/SRTP but Mandate only the support and not the use. > > > > The WG chairs are looking for which direction to take. I see three opti= ons > > > > 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 > > 2. DTLS/SRTP MUST be supported (and have some text about when no= t to > use) > > 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text > about when not to use) > > > > Please provide feedback about which text to use by April 15^th > > > > Note that the current text is option1 and if no comments it will need t= o stay > > > > Thanks > > Roni Even > > CLUE WG 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 Wed Apr 1 06:42: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 B00ED1A9113 for ; Wed, 1 Apr 2015 06:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzAJLmWHFyaw for ; Wed, 1 Apr 2015 06:42:25 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DA61A9109 for ; Wed, 1 Apr 2015 06:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2367; q=dns/txt; s=iport; t=1427895745; x=1429105345; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=z05oVJnBvufXW/r0RvZHjTu+q+2sHcbZFKqRdWuDZeY=; b=if/g1CJjpsgCDCUqocfOkt1GdRQO7uF1Y/LFn1TQKAZI6/qlp7DvdCNN uO1L8wUpgm2GV4Wdh8t8UNtDQG07usXJWLwNdAywKFIUms3ubt5WtsJN0 gwpvddr5ZMuKnR3Jp5Jv60nOmBZqpJkuK5e1C3iOomVBg0vYOb2unC89x o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsBAA19BtV/xbLJq1cg1hcsjMFAXuQUAaBRgqFcwKBdxQBAQEBAQEBfIQUAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgrDc5DAQEBAQEBAQEBAQEBAQEBAQEBFgSGD4UahH8GEIQXAQSaWYEdgzKCOo01IoIygT09MYJDAQEB X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="407050909" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Apr 2015 13:42:23 +0000 Received: from [10.47.200.89] ([10.47.200.89]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t31DgNVf029540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 1 Apr 2015 13:42:23 GMT Message-ID: <551BF5BF.9030503@cisco.com> Date: Wed, 01 Apr 2015 14:42:23 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <00be01d06bde$1355b480$3a011d80$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> <551BBF2D.1040904@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F96B2E856F3@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2E856F3@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 01 Apr 2015 13:42:31 -0000 I support #3, "media is protected using other means" being one of those cases where the implementer has a good reason to ignore the SHOULD. Rob On 01/04/15 13:38, Duckworth, Mark wrote: > +1 > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves >> Sent: Wednesday, April 01, 2015 5:50 AM >> To: clue@ietf.org >> Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CLUE >> signaling draft >> >> +1 >> >> Christian >> >> On 1/04/2015 6:58 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I support 2) or 3), and the when-not-to-use text would indicate that >>> there are environments where media is protected using other means. >>> >>> Regards, >>> >>> Christer >>> >>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even >>> *Sent:* 31. maaliskuuta 2015 21:11 >>> *To:* clue@ietf.org >>> *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in >>> CLUE signaling draft >>> >>> Hi, >>> >>> In IETF 91 there was according to the meeting notesRough consensus in favor >> of mandating DTLS/SRTP for all media in CLUE signaling draft. There was no >> follow up discussion on the list. >>> The topic was presented again in IETF92 and the comments were made for >> having DTLS/SRTP but Mandate only the support and not the use. >>> The WG chairs are looking for which direction to take. I see three options >>> >>> 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 >>> 2. DTLS/SRTP MUST be supported (and have some text about when not to >> use) >>> 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text >> about when not to use) >>> Please provide feedback about which text to use by April 15^th >>> >>> Note that the current text is option1 and if no comments it will need to stay >>> >>> Thanks >>> Roni Even >>> CLUE WG co-chair >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Apr 1 07:16:58 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 4FC0B1A92B8 for ; Wed, 1 Apr 2015 07:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA5W4ZAol4Bw for ; Wed, 1 Apr 2015 07:16:57 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8B61A916D for ; Wed, 1 Apr 2015 07:16:56 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-01v.sys.comcast.net with comcast id AeGJ1q0032AWL2D01eGv24; Wed, 01 Apr 2015 14:16:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id AeGv1q00D3Ge9ey01eGvSw; Wed, 01 Apr 2015 14:16:55 +0000 Message-ID: <551BFDD7.5050706@alum.mit.edu> Date: Wed, 01 Apr 2015 10:16:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: clue@ietf.org References: <00be01d06bde$1355b480$3a011d80$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D787868@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=1427897815; bh=LPWyICywZFQwXWMsLazmpr54SYFLZPJIPO7YyPsOTng=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=t1ikOgyUSIJEooBu8ATGGNfD8Fuo3140ONJVgwabK2WLRi4fJjOyV3UhnUJpzeHy3 YjyFoYTgY4+cT1kXoOWscdnf5b/TXELJ0560SSPqj3NStZ4OHGwfOSyyBRze3KqD1L xeXw2pVsMQQ9L+Lsjf5aqXWjj5GxEdPpL/Om0NlViCEOZokCpwTl1fQ3ewWg05n8PA eHCybEhYeScuo+DGyBo3+NJwp9dxi1Scdi+1iks25XIxwPB1es3oVBPOaiG7CV51kN o/M53bQDwBIQhMhtcaQeiU4Wgn6qSN8p3ppOaeIePaZnt/wO5vwy4+cXEWKNgShkB+ EEzFbcCKyVEEg== Archived-At: Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 01 Apr 2015 14:16:58 -0000 +1 On 4/1/15 3:58 AM, Christer Holmberg wrote: > Hi, > > I support 2) or 3), and the when-not-to-use text would indicate that > there are environments where media is protected using other means. > > Regards, > > Christer > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > *Sent:* 31. maaliskuuta 2015 21:11 > *To:* clue@ietf.org > *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in > CLUE signaling draft > > Hi, > > In IETF 91 there was according to the meeting notesRough consensus in favor of mandating DTLS/SRTP for all media in CLUE signaling draft. There was no follow up discussion on the list. > > The topic was presented again in IETF92 and the comments were made for having DTLS/SRTP but Mandate only the support and not the use. > > > > The WG chairs are looking for which direction to take. I see three options > > > > 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 > > 2. DTLS/SRTP MUST be supported (and have some text about when not to use) > > 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text about when not to use) > > > > Please provide feedback about which text to use by April 15^th > > > > Note that the current text is option1 and if no comments it will need to stay > > > > Thanks > > Roni Even > > CLUE WG co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Apr 1 13:59:58 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 35DA11A92E2; Wed, 1 Apr 2015 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXIoYutjB0OF; Wed, 1 Apr 2015 13:59:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F196F1A913E; Wed, 1 Apr 2015 13:59:54 -0700 (PDT) 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.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150401205954.29356.92823.idtracker@ietfa.amsl.com> Date: Wed, 01 Apr 2015 13:59:54 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-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: Wed, 01 Apr 2015 20:59:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-08.txt Pages : 62 Date : 2015-04-01 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-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 Thu Apr 2 06:15:00 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEDA1A87BD for ; Thu, 2 Apr 2015 06:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zar9G7opKoBh for ; Thu, 2 Apr 2015 06:14:58 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 02DEE1A8703 for ; Thu, 2 Apr 2015 06:14:57 -0700 (PDT) Received: by widjs5 with SMTP id js5so9196067wid.1 for ; Thu, 02 Apr 2015 06:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=fAqkZl78KoGTWkjnGBCISsJIOOrGM50+8PMJUJJAiUM=; b=WqqMOHquzZ+hjtCbNFG6DBVhutH9fYLvEzmRiExmP/0o9WUjHCBSOzSeBH7DS7wsgC x9yFjF6Gn/CVRmxrvYMufwpMJti8OwRq9yJp4c6mhKfvtFzksoZoIxQhl70b0EKo8xt7 dTDuowrQ8Gq5/lxh1RhSHUT2rTWBqZulhE0KFCIPsz4jiBm9BDReKXQbC+OakjRtM/O2 5zNKKnXN7ouhiHg8pO/4g6gD0EzCxuEsU27lLjdIGr7Gl6trM7lQwHDLBuPuXYS+qWEg jt35AKRZi5vNtIwi2ClsXRyQoObzom0pr7KvtaEjbCnDeUHpKoRhPuC7JfJc3L8aPJhN rYtg== X-Received: by 10.180.11.1 with SMTP id m1mr22480893wib.70.1427980496676; Thu, 02 Apr 2015 06:14:56 -0700 (PDT) Received: from RoniE (bzq-79-177-166-235.red.bezeqint.net. [79.177.166.235]) by mx.google.com with ESMTPSA id ff4sm19422732wib.9.2015.04.02.06.14.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 02 Apr 2015 06:14:55 -0700 (PDT) From: "Roni Even" To: Date: Thu, 2 Apr 2015 16:14:50 +0300 Message-ID: <019701d06d47$01940d90$04bc28b0$@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: AdBtRq4UGijt4L47S+W33OZVtOlmAA== Content-Language: en-us Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-08.txt - comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 13:14:59 -0000 Hi, I noticed that section 10.9 on policy ends with [to do]. As far as I can tell there is a definition in section 7.2.1.2 of the framework draft. So what is the [to do] here? Thanks Roni Even From nobody Thu Apr 2 09:09:49 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 B07C91B2D39 for ; Thu, 2 Apr 2015 09:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJPA6rxcKUnX for ; Thu, 2 Apr 2015 09:09:42 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA241ACDA1 for ; Thu, 2 Apr 2015 09:09:42 -0700 (PDT) X-ASG-Debug-ID: 1427990978-05f2751b141e1ef90001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 8fg7WBVwizfHRCyE (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Thu, 02 Apr 2015 18:09:38 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([143.225.229.123]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t32G9ckE030287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Apr 2015 18:09:38 +0200 Message-ID: <551D69C3.9050006@unina.it> Date: Thu, 02 Apr 2015 18:09:39 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Roni Even , clue@ietf.org References: <019701d06d47$01940d90$04bc28b0$@gmail.com> X-ASG-Orig-Subj: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-08.txt - comment In-Reply-To: <019701d06d47$01940d90$04bc28b0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1427990978 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.17488 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-data-model-schema-08.txt - comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:09:48 -0000 Hi Roni, thank you, that was an old editor's note. Version 8 has been uploaded to avoid the draft expiration, it still presents some typo. Before the end of next week, after Easter, we will upload the reviewed version (version 9) which should be the one ready for the last call. Regards, Roberta Il 02/04/2015 15:14, Roni Even ha scritto: > Hi, > I noticed that section 10.9 on policy ends with [to do]. As far as I can > tell there is a definition in section 7.2.1.2 of the framework draft. So > what is the [to do] here? > Thanks > Roni Even > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Apr 9 11:51: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 361E31A8827 for ; Thu, 9 Apr 2015 11:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpI3CUnQ1K9E for ; Thu, 9 Apr 2015 11:51:15 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 3CC421A87F0 for ; Thu, 9 Apr 2015 11:51:15 -0700 (PDT) Received: by ignm3 with SMTP id m3so802182ign.0 for ; Thu, 09 Apr 2015 11:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a+82f1CW6HLhk+ngdLEfYdJ05DIkp5XDzPUp9Em0Q24=; b=qeSZI31CmeqjkrzO3krqukofMjGD8qH+cFHZCkkf1Sw0UyNVu/ZE+qL6oxCuuH5HkN bq5VPmnahJvLhs0ZuxW6eTMatFlbnvFX1tkF98gqZhcGexhBjNl81nhew8jovX/ZoEdr eDYi2MmXw0kepe8T7bO35UxyFneY623shI7RYPt1Itkc2U3gPdNYEtb5GjBQ9BpyxoiH YqwicjdbiHUIx2DoA1a7aje5opW38RdLYjZsaS34Rfv+RLMpsAEokx08zqOKtyH5Y2HW O1U100DQYlA1X+xLbu+CmoHKqp8/srrkG25q4jYBiud1RxjFxCZLKadpYgTTpraYgEuk Ftpg== MIME-Version: 1.0 X-Received: by 10.107.35.70 with SMTP id j67mr49069745ioj.51.1428605474724; Thu, 09 Apr 2015 11:51:14 -0700 (PDT) Received: by 10.50.248.49 with HTTP; Thu, 9 Apr 2015 11:51:14 -0700 (PDT) In-Reply-To: <551BFDD7.5050706@alum.mit.edu> References: <00be01d06bde$1355b480$3a011d80$@gmail.com> <7594FB04B1934943A5C02806D1A2204B1D787868@ESESSMB209.ericsson.se> <551BFDD7.5050706@alum.mit.edu> Date: Thu, 9 Apr 2015 14:51:14 -0400 Message-ID: From: Stephen Botzko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1140dcf2d8632805134f212e Archived-At: Cc: CLUE Subject: Re: [clue] call on Mandating using DTLS/SRTP for all media in CLUE signaling 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, 09 Apr 2015 18:51:17 -0000 --001a1140dcf2d8632805134f212e Content-Type: text/plain; charset=UTF-8 +1 BR Stephen On Wed, Apr 1, 2015 at 10:16 AM, Paul Kyzivat wrote: > +1 > > On 4/1/15 3:58 AM, Christer Holmberg wrote: > >> Hi, >> >> I support 2) or 3), and the when-not-to-use text would indicate that >> there are environments where media is protected using other means. >> >> Regards, >> >> Christer >> >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even >> *Sent:* 31. maaliskuuta 2015 21:11 >> *To:* clue@ietf.org >> *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in >> CLUE signaling draft >> >> Hi, >> >> In IETF 91 there was according to the meeting notesRough consensus in >> favor of mandating DTLS/SRTP for all media in CLUE signaling draft. There >> was no follow up discussion on the list. >> >> The topic was presented again in IETF92 and the comments were made for >> having DTLS/SRTP but Mandate only the support and not the use. >> >> >> >> The WG chairs are looking for which direction to take. I see three options >> >> >> >> 1. DTLS/SRTP MUST be used as in the current 05 draft section 13 >> >> 2. DTLS/SRTP MUST be supported (and have some text about when not >> to use) >> >> 3. DTLS/SRTP MUST be supported and SHOULD be used (and some text >> about when not to use) >> >> >> >> Please provide feedback about which text to use by April 15^th >> >> >> >> Note that the current text is option1 and if no comments it will need to >> stay >> >> >> >> Thanks >> >> Roni Even >> >> CLUE WG co-chair >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a1140dcf2d8632805134f212e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

BR
Stephen

On Wed, Apr 1, 2015 a= t 10:16 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:<= br>
+1

On 4/1/15 3:58 AM, Christer Holmberg wrote:
Hi,

I support 2) or 3), and the when-not-to-use text would indicate that
there are environments where media is protected using other means.

Regards,

Christer

 *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even
*Sent:* 31. maaliskuuta 2015 21:11
*To:* clue@ietf.org<= br> *Subject:* [clue] call on Mandating using DTLS/SRTP for all media in
CLUE signaling draft

Hi,

In IETF 91 there was according to the meeting notesRough consensus in favor= of mandating DTLS/SRTP for all media in CLUE signaling draft. There was no= follow up discussion on the list.

The topic was presented again in IETF92 and the comments were made for havi= ng DTLS/SRTP but Mandate only the support and not the use.



The WG chairs are looking for which direction to take. I see three options<= br>


1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS/SRTP MUST be used as in the current 05 d= raft section 13

2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS/SRTP MUST be supported (and have some te= xt about when not to use)

3.=C2=A0 =C2=A0 =C2=A0 =C2=A0 DTLS/SRTP MUST be supported and SHOULD be use= d (and some text about when not to use)



 Please provide feedback about which text to use by April 15^th



Note that the current text is option1 and if no comments it will need to st= ay



Thanks

Roni Even

CLUE WG co-chair



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


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

--001a1140dcf2d8632805134f212e-- From nobody Sun Apr 12 04:08:56 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 C56A71B3775 for ; Sun, 12 Apr 2015 04:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n71p-pIrChbS for ; Sun, 12 Apr 2015 04:08:54 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE241B3773 for ; Sun, 12 Apr 2015 04:08:53 -0700 (PDT) Received: by widdi4 with SMTP id di4so23987689wid.0 for ; Sun, 12 Apr 2015 04:08:52 -0700 (PDT) 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=A0P7Mfu9Mkywag1wsKzduGnmpSM3YuQnHM+fhAd+tnI=; b=zrvCtXj8bzoRO7Z5Q0Bsr06OgdARXDamqX+McU8J6uPA2Oi/Cm1sti5/2Yd/bvbcAH 6xyois11cs+OHCY7Krnczt7WGiM7XtyfjA6GE7V+X/RphQ+LYbK8P5fqCBbZQpj42Vl/ CpYXM+vukBZI8BbsE/QnJ2EJ7t2cLb6/lzVB+ed6cNQ0bB7skzbyYSmYccdCNdhcX8c2 1taWW6VJCATAf4NI0+EaLQ9cQKtVqp+MpiT1yNX0bQlGagc4iG4Um1yMwJdzQqOV7Bg5 kWrNczUOXkgm87snhbLFi8VZniZ/wt4/oinJLkxlUBOGjb4sj8+lTANbscFuh0oJ9a5u zSWg== X-Received: by 10.194.223.5 with SMTP id qq5mr18785357wjc.152.1428836932655; Sun, 12 Apr 2015 04:08:52 -0700 (PDT) Received: from RoniE (bzq-79-179-184-158.red.bezeqint.net. [79.179.184.158]) by mx.google.com with ESMTPSA id o5sm11839624wia.0.2015.04.12.04.08.49 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 12 Apr 2015 04:08:52 -0700 (PDT) From: "Roni Even" To: "'Simon Pietro Romano'" , , "'Rob Hansen \(rohanse2\)'" , "Paul Kyzivat" Date: Sun, 12 Apr 2015 14:08:47 +0300 Message-ID: <014c01d07511$0ebaee90$2c30cbb0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014D_01D0752A.34089BC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdB1EQxW3tqv1xP3SrmSCP32oenI0g== Content-Language: en-us Archived-At: Cc: clue@ietf.org, 'Jonathan Lennox' Subject: [clue] Plan to finalize CLUE documents X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 11:08:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014D_01D0752A.34089BC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi guys, As we discussed in Dallas based on the maturity of the current documents , we should try to finish the WGLC and ask for publication on the data model schema, protocol, signaling and RTP mapping before the July meeting. In order to get there we may need one more revision of the current documents and I hope we can have them this month (first week of May), so that we can ask for reviews (also for SDP, XML and security). The plan is to have a review by the volunteers and after addressing the comments to start a WGLC which should not bring any major issues if we get a good earlier review. If the authors feel that the current versions are good for a review let us know and we will start the review process. I do not see any need to have conference calls on any of the drafts but if any of the authors thinks that it will be helpful we can have one. Thanks Roni Even CLUE co-chair ------=_NextPart_000_014D_01D0752A.34089BC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = guys,

As we discussed in Dallas based = on the maturity of the current documents , we should try to finish the = WGLC and ask for publication on the data model  schema, protocol, = signaling and RTP mapping before the July meeting.

In order to get there we may need one more revision of = the current documents and I hope we can have them this month (first week = of May), so that we can ask for reviews (also for SDP, XML and = security).

 

The plan is to have a review by the volunteers and = after addressing the comments to start a WGLC which should not bring any = major issues if we get a good earlier review.

 

If the = authors feel that the current versions are good for a review let us know = and we will start the review process.

I do not see any need to have  conference calls = on any of the drafts but if any of the authors thinks that it will be = helpful we can have one.

 

Thanks

Roni = Even

CLUE = co-chair

------=_NextPart_000_014D_01D0752A.34089BC0-- From nobody Mon Apr 13 16:02: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 BFBB61B2AF0; Mon, 13 Apr 2015 16:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y5kY47emHAF; Mon, 13 Apr 2015 16:02:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8D91B2AE7; Mon, 13 Apr 2015 16:02:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150413230215.26686.13435.idtracker@ietfa.amsl.com> Date: Mon, 13 Apr 2015 16:02:15 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-22.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 23:02:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-22.txt Pages : 83 Date : 2015-04-13 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-22 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 13 16:04:26 2015 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFBF01B2AE9 for ; Mon, 13 Apr 2015 16:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 810n_A0QFPHr for ; Mon, 13 Apr 2015 16:04:24 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6704A1B2AE6 for ; Mon, 13 Apr 2015 16:04:24 -0700 (PDT) Received: from [216.82.254.20] by server-14.bemta-7.messagelabs.com id CC/46-25228-77B4C255; Mon, 13 Apr 2015 23:04:23 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-47.messagelabs.com!1428966263!16154370!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.13.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8041 invoked from network); 13 Apr 2015 23:04:23 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-7.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 13 Apr 2015 23:04:23 -0000 Received: from CRPMBOXPRD08.polycom.com ([169.254.1.92]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 13 Apr 2015 16:03:12 -0700 From: "Duckworth, Mark" To: "'clue@ietf.org'" Date: Mon, 13 Apr 2015 16:04:21 -0700 Thread-Topic: Minor changes in framework-22 Thread-Index: AdB2PhgWFQ9tWXONSE6Ny8Mp5HQ/xg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F96B2E860CA@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_5C4AC54BFF7A0842A6A11F554D6FB52F96B2E860CACRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: Subject: [clue] Minor changes in framework-22 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 23:04:25 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2E860CACRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Add missing references. 2. Update version number of referenced working group drafts. 3. Minor updates for idnits issues. Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2E860CACRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1. Add missing r= eferences.

2. Update version number of r= eferenced working group drafts.

3. Minor= updates for idnits issues.

 <= /o:p>

Regards,

M= ark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F96B2E860CACRPMBOXPRD08p_-- From nobody Fri Apr 17 08:46: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 198711A19FE; Fri, 17 Apr 2015 08:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y02JUoMbTt8E; Fri, 17 Apr 2015 08:46:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B911A6F05; Fri, 17 Apr 2015 08:46:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150417154635.15349.533.idtracker@ietfa.amsl.com> Date: Fri, 17 Apr 2015 08:46:35 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-data-model-schema-09.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, 17 Apr 2015 15:46:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : An XML Schema for the CLUE data model Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-data-model-schema-09.txt Pages : 62 Date : 2015-04-17 Abstract: This document provides an XML schema file for the definition of CLUE data model types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-data-model-schema/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-data-model-schema-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-data-model-schema-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 22 09:54: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 D384E1B380A; Wed, 22 Apr 2015 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBwMWqqsQ_WF; Wed, 22 Apr 2015 09:54:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A77691B37F7; Wed, 22 Apr 2015 09:54:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150422165411.6359.9895.idtracker@ietfa.amsl.com> Date: Wed, 22 Apr 2015 09:54:11 -0700 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 16:54:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-04.txt Pages : 53 Date : 2015-04-22 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 [RFC7262]. The companion document [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well as on the SIP/SDP session establishment phase. CLUE messages flow upon the CLUE data channel, based on reliable and ordered SCTP over DTLS transport, as described in [I-D.ietf-clue-datachannel]. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-protocol-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 22 10:01: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 48C7B1B383A for ; Wed, 22 Apr 2015 10:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.34 X-Spam-Level: * X-Spam-Status: No, score=1.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyQWmMF2zES8 for ; Wed, 22 Apr 2015 10:01:14 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452381B3816 for ; Wed, 22 Apr 2015 10:00:36 -0700 (PDT) X-ASG-Debug-ID: 1429722032-05f27518bf37d5be0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id fTWSu9lqrSCCZni0 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2015 19:00:32 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id t3MH0U7G026025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Apr 2015 19:00:30 +0200 Message-ID: <5537D3AE.9050000@unina.it> Date: Wed, 22 Apr 2015 19:00:30 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Christian Groves References: <550A474C.9090005@nteczone.com> X-ASG-Orig-Subj: Re: [clue] Review of draft-ietf-clue-protocol-03 In-Reply-To: <550A474C.9090005@nteczone.com> Content-Type: multipart/alternative; boundary="------------000408020805050704050505" X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1429722032 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Review of draft-ietf-clue-protocol-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:01:17 -0000 This is a multi-part message in MIME format. --------------000408020805050704050505 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit Dear Christian, we have updated the protocol draft according to your comments. Thank you for the review. Please find below some answers. Regards, Roberta Il 19/03/2015 04:49, Christian Groves ha scritto: > Cl.4 clueID: Should we recommend a particular format for this e.g. URI > or similar instead of just a simple string? > We have left the definition of the clueID as is. The alternative is to change the XS definition by specifying the xs:anyUri type and by adding in the document both the textual specification and the IANA consideration for the CLUE-URI definition, as follows: * XS definition: * XML example: clue:alice@unina.it * Textual specification of the CLUE-URI for the CP: o The element contains the CLUE-URI of the CP. The CLUE-URI of the CP identifies the CP in the CLUE-enabled telepresence session at the CLUE application level. o The syntax is defined by the following ABNF [RFC5234] rules. + CLUE-URI = "clue" ":" [cp-id-string "@"] host + cp-id-string = 1*( unreserved / "+" / "=" / "/" ) o Note: host and unreserved are defined in RFC 3986 [RFC3986]. o A CLUE-URI is not designed to be resolved, and an application MUST NOT attempt to perform a standard DNS lookup on the host portion of such a URI in an attempt to discover an IP address or port at which to connect. * IANA consideration: o URI scheme name: clue o ... Should the framework include such a definition? > Cl.4 I don't understand the significance of "/Each CP should manage up > to three streams of sequence numbers: (i) one for the messages > exchanged in the initiation phase, (ii) one for the messages exchanged > as MP, and (iii) one for the messages exchanged as MC./"**Would it > just have to manage the sequence numbers it sent vs received sequence > numbers? Why would it have to have multiple streams of numbers? There are three distinct CLUE dialogues (i.e., the one of the initiation phase, the one performed as a MP, and the one performed as a MC) with associated mechanisms involving sequence numbers, so they should be separate. > > Cl.4.7 "Examples of response codes" would suggest that this list is > informative and there are other response codes. Perhaps we should say > "The response codes and strings defined for use with CLUE are as > follows:"? We have made some changes in the section about response codes. We have associated a meaning to response codes on the basis of the first digit of the code. The response codes defined are mandatory, but other response codes can be used, provided that they respect the XS definition, the semantic associated to the first digit, and do not overwrite existing codes. > Cl.6 4th para: "... if the telepresence session ends" is that > referring to disabling CLUE or the SIP session ending? "Telepresence > session" is used several times so it would be good to define what it > exactly means. I guess this really is "CLUE session". > The "session ends" event refers to the SDP negotiation for removing the CLUE channel. We have added such specification in the draft. > Cl.6 5th para: What happens if the CI and CR are unable to agree on a > mutual CLUE version. i.e. CI support v1.5 and CR only support v2.5. Is > the error code 312 (or 510) sufficient for this? > Yes, it is. > Cl.6 Pg17 "/If the CP receives a further OPTIONS/OPTIONS RESPONSE > message, it MUST ignore the message and stay in the ACTIVE state./" > This implies then that options or version can never be negotiated > whilst CLUE is enabled and these messages can only be successful sent > once. I think it would be good to make this clear in section 4.1/4.2. > We have added claryfing text in the introduction section when the initiation phase is introduced. > Cl.6.1 3rd para: "In case of a timeout..." this follows text regarding > the CONF arrival. Is this timeout related to a MP never receiving a CONF? Yes, it is. Replaced with "If the CONF does not arrive within the timeout interval and the retry threshold has not been overcome". > Cl.6.2 3rd para: I wonder if we need a note here outlining the > interaction with SDP for the encodings here before a CONF can be sent. > I don't think we need to go into detail but it may be helpful to > reference the relevant section in the CLUE signalling draft. We added a reference to the signaling draft for the interaction between CLUE and SDP in the introductory part of the state machines section. > > Cl6.2 State diagram: It shows CONF+ACK sent transitioning from ADV > processing to WAIT FOR CONF RESPONSE. I wonder if this should > transition through the CONF state? This seems more natural as there > will help to be other inputs into the selection of > configures/encodings that wouldn't necessarily occur in a ADV > processing state. > We prefer to keep the transitions separate. In order to clarify the description, we changed the text of the ADV PROCESSING state as follows: "In the ADV PROCESSING state, the ADV is parsed by the MC. If the ADV is successfully processed, there are two possibilities. According to the first one, the MC issues a successful ACK message to the MP ("ACK sent") and moves to the CONF state. In the second one, the MC prepares and sends a CONF message with the field set to "true" ("CONF+ACK sent") and goes directly to the WAIT FOR CONF RESPONSE state. " > > Cl.11.2: The MCC example needs to have "Allow Subset Choice" from the > Framework. This isn't reflected in the data model yet. We updated the MCC ADV example by adding the element that has been added also into the data model schema (version 9, to appear). ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille --------------000408020805050704050505 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 8bit
Dear Christian,
we have updated the protocol draft according to your comments.
Thank you for the review.
Please find below some answers.
Regards,

Roberta

Il 19/03/2015 04:49, Christian Groves ha scritto:
Cl.4 clueID: Should we recommend a particular format for this e.g. URI or similar instead of just a simple string?

We have left the definition of the clueID as is.
The alternative is to change the XS definition by specifying the xs:anyUri type and by adding in the document both the textual specification and the IANA consideration for the CLUE-URI definition, as follows:

  • XS definition: <xs:element name="clueId" type="xs:anyUri"/>
  • XML example: <clueId>clue:alice@unina.it</clueId>
  • Textual specification of the CLUE-URI for the CP: 
    • The <clueId> element contains the CLUE-URI of the CP. The CLUE-URI of the CP identifies the CP in the CLUE-enabled telepresence session at the CLUE application level.
    • The syntax is defined by the following ABNF [RFC5234] rules.
      • CLUE-URI = "clue" ":" [cp-id-string "@"] host
      • cp-id-string = 1*( unreserved / "+" / "=" / "/" )
    • Note: host and unreserved are defined in RFC 3986 [RFC3986].
    • A CLUE-URI is not designed to be resolved, and an application MUST NOT attempt to perform a standard DNS lookup on the host portion of such a URI in an attempt to discover an IP address or port at which  to connect.
  • IANA consideration:
    • URI scheme name: clue
    • ...
Should the framework include such a definition?

Cl.4 I don't understand the significance of "/Each CP should manage up to three streams of sequence numbers: (i) one for the messages exchanged in the initiation phase, (ii) one for the messages exchanged as MP, and (iii) one for the messages exchanged as MC./"**Would it just have to manage the sequence numbers it sent vs received sequence numbers? Why would it have to have multiple streams of numbers?
There are three distinct CLUE dialogues (i.e., the one of the initiation phase, the one performed as a MP, and the one performed as a MC) with associated mechanisms involving sequence numbers, so they should be separate.


Cl.4.7 "Examples of response codes" would suggest that this list is informative and there are other response codes. Perhaps we should say "The response codes and strings defined for use with CLUE are as follows:"?
We have made some changes in the section about response codes.
We have associated a meaning to response codes on the basis of the first digit of the code. The response codes defined are mandatory, but other response codes can be used, provided that they respect the XS definition, the semantic associated to the first digit, and do not overwrite existing codes.

Cl.6 4th para: "... if the telepresence session ends" is that referring to disabling CLUE or the SIP session ending? "Telepresence session" is used several times so it would be good to define what it exactly means. I guess this really is "CLUE session".

The "session ends" event  refers to the SDP negotiation for removing the CLUE channel.
We have added such specification in the draft.

Cl.6 5th para: What happens if the CI and CR are unable to agree on a mutual CLUE version. i.e. CI support v1.5 and CR only support v2.5. Is the error code 312 (or 510) sufficient for this?

Yes, it is.

Cl.6 Pg17 "/If the CP receives a further OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay in the ACTIVE state./" This implies then that options or version can never be negotiated whilst CLUE is enabled and these messages can only be successful sent once. I think it would be good to make this clear in section 4.1/4.2.

We have added claryfing text in the introduction section when the initiation phase is introduced.

Cl.6.1 3rd para: "In case of a timeout..." this follows text regarding the CONF arrival. Is this timeout related to a MP never receiving a CONF?
Yes, it is. Replaced with "If the CONF does not arrive within the timeout interval and the retry threshold has not been overcome".

Cl.6.2 3rd para: I wonder if we need a note here outlining the interaction with SDP for the encodings here before a CONF can be sent. I don't think we need to go into detail but it may be helpful to reference the relevant section in the CLUE signalling draft.
We added a reference to the signaling draft for the interaction between CLUE and SDP in the introductory part of the state machines section.

Cl6.2 State diagram: It shows CONF+ACK sent transitioning from ADV processing to WAIT FOR CONF RESPONSE. I wonder if this should transition through the CONF state? This seems more natural as there will help to be other inputs into the selection of configures/encodings that wouldn't necessarily occur in a ADV processing state.

We prefer to keep the transitions separate.
In order to clarify the description, we changed the text of the ADV PROCESSING state as follows:
"In the ADV PROCESSING state, the ADV is parsed by the MC. If the ADV is successfully processed, there are two possibilities. According to the first one, the MC issues a successful ACK message to the MP ("ACK sent") and moves to the CONF state. In the second one, the MC prepares and sends a CONF message with the <ack> field set to "true" ("CONF+ACK sent") and goes directly to the WAIT FOR CONF RESPONSE state. "


Cl.11.2: The MCC example needs to have "Allow Subset Choice" from the Framework. This isn't reflected in the data model yet.
We updated the MCC ADV example by adding the <allowSubsetChoice> element that has been added also into the data model schema (version 9, to appear).



----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

  ­­   --------------000408020805050704050505-- From nobody Wed Apr 22 10:10: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 8F0E21B3872 for ; Wed, 22 Apr 2015 10:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.139 X-Spam-Level: ** X-Spam-Status: No, score=2.139 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wSVbMNLnG8Z for ; Wed, 22 Apr 2015 10:09:54 -0700 (PDT) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581FA1B386E for ; Wed, 22 Apr 2015 10:09:54 -0700 (PDT) X-ASG-Debug-ID: 1429722591-05ce37732530ee4b0001-dOUo1C Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id MzMTjYBxpmPN1prs (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 22 Apr 2015 19:09:51 +0200 (CEST) X-Barracuda-Envelope-From: roberta.presta@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id t3MH9o7Z017879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 22 Apr 2015 19:09:51 +0200 Message-ID: <5537D5DF.2050706@unina.it> Date: Wed, 22 Apr 2015 19:09:51 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=iso-8859-15; format=flowed X-ASG-Orig-Subj: signaling v5, references to obsolete protocol state machines Content-Transfer-Encoding: 8bit X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1429722591 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-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.18242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: Subject: [clue] signaling v5, references to obsolete protocol state machines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:09:55 -0000 Dear all, in Section 5.1 of the signaling draft, last paragraph, there is a reference to obsolete state machines (protocol draft version 1). In the current state machines, there aren't state transitions related to SDP negotiations. I propose to simply replace the text as follows: "A device with the CLUE participant state machine in the ACTIVE state MAY choose not to send a new ADV or a new CONF based on the SDP state. Similarly, a device MAY choose to delay initiating a new SDP exchange based on the state of their CLUE state machines." Otherwise, another possibility is replacing the old state names with the new ones. The paragraph would then look as follows: "A device with the CLUE participant state machine in the ACTIVE state MAY choose not to move from ESTABLISHED to ADV (media provider state machine) or from CONF to WAIT FOR CONF RESPONSE (media consumer state machine) based on the SDP state. See [I-D.ietf-clue-protocol] for CLUE state machine specifics. Similarly, a device MAY choose to delay initiating a new SDP exchange based on the state of their CLUE state machines." Regards, Roberta ---- 5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI NAPOLI Codice Fiscale: 00876220633 www.unina.it/Vademecum5permille From nobody Thu Apr 23 18:43: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 DCBE01B34DF for ; Thu, 23 Apr 2015 18:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_26=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2rQ3g5oPxdl for ; Thu, 23 Apr 2015 18:43:37 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED0EC1B34DC for ; Thu, 23 Apr 2015 18:43:03 -0700 (PDT) Received: from ppp118-209-44-171.lns20.mel4.internode.on.net ([118.209.44.171]:54847 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YlSd7-0004xb-EM; Fri, 24 Apr 2015 11:42:09 +1000 Message-ID: <55399F9D.4030809@nteczone.com> Date: Fri, 24 Apr 2015 11:42:53 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Roberta Presta References: <550A474C.9090005@nteczone.com> <5537D3AE.9050000@unina.it> In-Reply-To: <5537D3AE.9050000@unina.it> Content-Type: text/plain; charset=iso-8859-15; 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: Cc: "clue@ietf.org" Subject: Re: [clue] Review of draft-ietf-clue-protocol-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 01:43:39 -0000 Hello Roberta, Thanks for the answers. Please see my responses below. Regards, Christian On 23/04/2015 3:00 AM, Roberta Presta wrote: > Dear Christian, > we have updated the protocol draft according to your comments. > Thank you for the review. > Please find below some answers. > Regards, > > Roberta > > Il 19/03/2015 04:49, Christian Groves ha scritto: >> Cl.4 clueID: Should we recommend a particular format for this e.g. >> URI or similar instead of just a simple string? >> > We have left the definition of the clueID as is. > The alternative is to change the XS definition by specifying the > xs:anyUri type and by adding in the document both the textual > specification and the IANA consideration for the CLUE-URI definition, > as follows: > > * XS definition: > * XML example: clue:alice@unina.it > * Textual specification of the CLUE-URI for the CP: > o The element contains the CLUE-URI of the CP. The > CLUE-URI of the CP identifies the CP in the CLUE-enabled > telepresence session at the CLUE application level. > o The syntax is defined by the following ABNF [RFC5234] rules. > + CLUE-URI = "clue" ":" [cp-id-string "@"] host > + cp-id-string = 1*( unreserved / "+" / "=" / "/" ) > o Note: host and unreserved are defined in RFC 3986 [RFC3986]. > o A CLUE-URI is not designed to be resolved, and an application > MUST NOT attempt to perform a standard DNS lookup on the host > portion of such a URI in an attempt to discover an IP address > or port at which to connect. > * IANA consideration: > o URI scheme name: clue > o ... > > Should the framework include such a definition? [CNG] I'm not sure. clueID isn't covered by the framework. The protocol document defines it as: "clueId: an XML element containing the identifier of the CP within the telepresence system;" It doesn't say what it is actually used for. There no uniqueness requirement. So its hard to say whether we need a formal specification or not? > >> Cl.4 I don't understand the significance of "/Each CP should manage >> up to three streams of sequence numbers: (i) one for the messages >> exchanged in the initiation phase, (ii) one for the messages >> exchanged as MP, and (iii) one for the messages exchanged as >> MC./"**Would it just have to manage the sequence numbers it sent vs >> received sequence numbers? Why would it have to have multiple streams >> of numbers? > There are three distinct CLUE dialogues (i.e., the one of the > initiation phase, the one performed as a MP, and the one performed as > a MC) with associated mechanisms involving sequence numbers, so they > should be separate. [CNG] I think I'm having trouble with the word "streams" maybe it would be better to say "... manage up to three sets of sequence...". > >> >> Cl.4.7 "Examples of response codes" would suggest that this list is >> informative and there are other response codes. Perhaps we should say >> "The response codes and strings defined for use with CLUE are as >> follows:"? > We have made some changes in the section about response codes. > We have associated a meaning to response codes on the basis of the > first digit of the code. The response codes defined are mandatory, but > other response codes can be used, provided that they respect the XS > definition, the semantic associated to the first digit, and do not > overwrite existing codes. [CNG] OK > >> Cl.6 4th para: "... if the telepresence session ends" is that >> referring to disabling CLUE or the SIP session ending? "Telepresence >> session" is used several times so it would be good to define what it >> exactly means. I guess this really is "CLUE session". >> > The "session ends" event refers to the SDP negotiation for removing > the CLUE channel. > We have added such specification in the draft. [CNG] OK > >> Cl.6 5th para: What happens if the CI and CR are unable to agree on a >> mutual CLUE version. i.e. CI support v1.5 and CR only support v2.5. >> Is the error code 312 (or 510) sufficient for this? >> > Yes, it is. [CNG] I see that error code 400 is now defined for this. > >> Cl.6 Pg17 "/If the CP receives a further OPTIONS/OPTIONS RESPONSE >> message, it MUST ignore the message and stay in the ACTIVE state./" >> This implies then that options or version can never be negotiated >> whilst CLUE is enabled and these messages can only be successful sent >> once. I think it would be good to make this clear in section 4.1/4.2. >> > We have added claryfing text in the introduction section when the > initiation phase is introduced. [CNG] OK > >> Cl.6.1 3rd para: "In case of a timeout..." this follows text >> regarding the CONF arrival. Is this timeout related to a MP never >> receiving a CONF? > Yes, it is. Replaced with "If the CONF does not arrive within the > timeout interval and the retry threshold has not been overcome". [CNG] OK > >> Cl.6.2 3rd para: I wonder if we need a note here outlining the >> interaction with SDP for the encodings here before a CONF can be >> sent. I don't think we need to go into detail but it may be helpful >> to reference the relevant section in the CLUE signalling draft. > We added a reference to the signaling draft for the interaction > between CLUE and SDP in the introductory part of the state machines > section. [CNG] OK >> >> Cl6.2 State diagram: It shows CONF+ACK sent transitioning from ADV >> processing to WAIT FOR CONF RESPONSE. I wonder if this should >> transition through the CONF state? This seems more natural as there >> will help to be other inputs into the selection of >> configures/encodings that wouldn't necessarily occur in a ADV >> processing state. >> > We prefer to keep the transitions separate. > In order to clarify the description, we changed the text of the ADV > PROCESSING state as follows: > "In the ADV PROCESSING state, the ADV is parsed by the MC. If the ADV > is successfully processed, there are two possibilities. According to > the first one, the MC issues a successful ACK message to the MP ("ACK > sent") and moves to the CONF state. In the second one, the MC prepares > and sends a CONF message with the field set to "true" ("CONF+ACK > sent") and goes directly to the WAIT FOR CONF RESPONSE state. " [CNG] OK > >> >> Cl.11.2: The MCC example needs to have "Allow Subset Choice" from the >> Framework. This isn't reflected in the data model yet. > We updated the MCC ADV example by adding the > element that has been added also into the data model schema (version > 9, to appear). [CNG] OK > > > > ---- > 5x1000 AI GIOVANI RICERCATORI > DELL'UNIVERSITA' DI NAPOLI > Codice Fiscale: 00876220633 > www.unina.it/Vademecum5permille > > ­­ From nobody Thu Apr 23 18:44:30 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 BBD7B1B34DD for ; Thu, 23 Apr 2015 18:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vazarGY8Y53N for ; Thu, 23 Apr 2015 18:44:27 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187081B348A for ; Thu, 23 Apr 2015 18:44:27 -0700 (PDT) Received: from ppp118-209-44-171.lns20.mel4.internode.on.net ([118.209.44.171]:54850 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1YlSeU-0005AI-8o for clue@ietf.org; Fri, 24 Apr 2015 11:43:34 +1000 Message-ID: <55399FF3.6030602@nteczone.com> Date: Fri, 24 Apr 2015 11:44:19 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5537D5DF.2050706@unina.it> In-Reply-To: <5537D5DF.2050706@unina.it> Content-Type: text/plain; charset=iso-8859-15; 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] signaling v5, references to obsolete protocol state machines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2015 01:44:28 -0000 Hello Roberta, I'm OK with either. A slight preference for the first option. Regards, Christian On 23/04/2015 3:09 AM, Roberta Presta wrote: > Dear all, > > in Section 5.1 of the signaling draft, last paragraph, there is a > reference to obsolete state machines (protocol draft version 1). > In the current state machines, there aren't state transitions related > to SDP negotiations. > I propose to simply replace the text as follows: > > "A device with the CLUE participant state machine in the ACTIVE state > MAY choose not to send a new ADV or a new CONF based on the SDP state. > Similarly, a device MAY choose to delay initiating a new SDP exchange > based on the state of their CLUE state machines." > > Otherwise, another possibility is replacing the old state names with > the new ones. The paragraph would then look as follows: > "A device with the CLUE participant state machine in the ACTIVE state > MAY choose not to move from ESTABLISHED to ADV (media provider state > machine) or from CONF to WAIT FOR CONF RESPONSE (media consumer state > machine) based on the SDP state. See [I-D.ietf-clue-protocol] for > CLUE state machine specifics. Similarly, a device MAY choose to delay > initiating a new SDP exchange based on the state of their CLUE state > machines." > > Regards, > > Roberta > > ---- > 5x1000 AI GIOVANI RICERCATORI > DELL'UNIVERSITÀ DI NAPOLI > Codice Fiscale: 00876220633 > www.unina.it/Vademecum5permille > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >